CODEWITHSUNDEEP
cpointerssizeof
Cloud
Cloud

Reputation: 19333

sizeof Pointer differs for data type on same architecture

I have been going through some posts and noticed that pointers can be different sizes according to sizeof depending on the architecture the code is compiled for and running on. Seems reasonable enough to me (ie: 4-byte pointers on 32-bit architectures, 8-byte on 64-bit, makes total sense).

One thing that surprises me is that the size of a pointer can different based on the data type it points to. I would have assumed that, on a 32-bit architecture, all pointers would be 4-bytes in size, but it turns out that function pointers can be a different size (ie: larger than what I would have expected). Why is this, in the C programming language? I found an article that explains this for C++, and how the program may have to cope with virtual functions, but this doesn't seem to apply in pure C. Also, it seems the use of "far" and "near" pointers is no longer necessary, so I don't see those entering the equation.

So, in C, what justification, standard, or documentation describes why not all pointers are the same size on the same architecture?

Thanks!

Upvotes: 5

Views: 589

Answers (5)

supercat
supercat

Reputation: 81115

Some architecture support multiple kinds of address spaces. While nothing in the Standard would require that implementations provide access to all address spaces supported by the underlying platform, and indeed the Standard offers no guidance as to how such support should be provided, the ability to support multiple address spaces may make it possible for a programmer who is aware of them to write code that works much better than would otherwise be possible.

On some platforms, one address space will contain all the others, but accessing things in that address space will be slower (sometimes by 2x or more) than accessing things which are known to be in a particular part of it. On other platforms, there won't be any "master" address space, so different kinds of pointers will be needed to access things in different spaces.

I disagree with the claim that the existence of multiple address spaces should be viewed as a relic. On a number of ARM processors, it would be possible for a program to have up to 1K-4K (depending upon the exact chip) of globals which could be accessed twice as quickly as--and with less code than--"normal" global variables. I don't know of any ARM compilers that would exploit that, but there's no reason a compiler for the ARM couldn't do so.

Upvotes: 1

paulsm4
paulsm4

Reputation: 121599

One additional point:

Q: So, is it safe to say that, while I don't have to explicitly use the far/near keywords when defining a pointer, this is handled automatically "under the hood" by the compiler?

A: http://www.unix.com/programming/45002-far-pointer.html

It's a historical anachronism from segmented architectures such as the 8086.

Back in the days of yore there was the 8080, this was an 8 bit processor with 16 bit address bus, hence 16 bit pointers.

Along came the 8086, in order to support some level of backward compatiblity it adopted a segmented architecture which let use use either 16 bit, 20 bit or 32 bit pointers depending on the day of the week. Where a pointer was a combination of 16 bit segment register and 16 bit near offset. This lead to the rise of tiny, small, medium, large and huge memory models with near, far and huge pointers.

Other architectures such as 68000 did not adopt this scheme and had what is called a flat memory model.

With the 80386 and true 32 bit mode, all pointers are 32 bit, but ironically are now really near pointers but 32 bit wide, the operating system hides the segments from you.

Upvotes: 1

haccks
haccks

Reputation: 105992

So, in C, what justification, standard, or documentation describes why not all pointers are the same size on the same architecture?

C11 : 6.2.5 p(28):

A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements.

6.3.2.3 Pointers p(8):

A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the pointed-to type, the behavior is undefined.

This clarifies that pointers to data and pointers to functions are not of the same size.

Upvotes: 3

Deduplicator
Deduplicator

Reputation: 45654

The C standard lays down the law on what's required:

  • All data pointers can be converted to void* and back without loss of information.
  • All struct-pointers have the same representation+alignment and can thus be converted to each other.
  • All union-pointers have the same representation+alignment and can thus be converted to each other.
  • All character pointers and void pointers have the same representation+alignment.

  • All pointers to qualified and unqualified compatible types shall have the same representation+alignment. (For example unsigned / signed versions of the same type are compatible)

  • All function pointers have the same representation+alignment and can be converted to any other function pointer type and back again.

Nothing more is required.
The committee arrived at these guarantees by examining all current implementations and machines and codifying as many guarantees as they could.

On architectures where pointers are naturally word pointers instead of character pointers, you get data pointers of different sizes.
On architectures with different size code / data spaces (many micro-processors), or where additional info is needed for properly invoking functions (like itanium, though they often hide that behind a data-pointer), you get code pointers of different size from data pointers.

Upvotes: 8

paulsm4
paulsm4

Reputation: 121599

I compiled this on three different platforms; the char * pointer was identical to the function pointer in every case:

CODE:

#include <stdio.h>

int main (int argc, char *argv[]) {
  char * cptr = NULL;
  void (*fnptr)() = NULL;

  printf ("sizeof cptr=%ld, sizeof fnptr=%ld\n",
    sizeof (cptr), sizeof (fnptr));

  return 0;
}

RESULTS:

                     char ptr    fn ptr
                     --------    ------
Win8/MSVS 2013       4           4
Debian7/i686/GCC     4           4
Centos/amd64/GCC     8           8

Upvotes: 0

Related Questions