Are all data pointers the same size in one platform for all data types?

Are char*, int*, long* or even long long* of same size (on a given platform)?

They're not guaranteed to be the same size, although on the platforms I have experience with they usually are.

C 2011 online draft:

6.2.5 Types
...
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.

---

^{48) The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions.}

Not necessarily. The standard does not guarantee sizeof(double*) == sizeof(int*). For instance, assume a processor with two address buses with different widths (like on some Harvard architecture processors) it could have pointers with different sizes.

On 16-bit embedded processors which have banked (paged) RAM and/or flash, the use of pages may lead to pointers being different sizes - though this is independent of the size of the data they point to.

For example, on Freescale's HCS12 processor which has banked flash, data pointers are all 16 bits.

However, function pointers are 16 bits for near pointers (for code in the same page as the calling function, or in unbanked flash), or 24 bits for far pointers (for code in a different page), incorporating the page number in the address.

Things are complicated if you want to store constant data in paged flash, as due to the limitation on data pointer size, the function using the data has to be in the same page as the data being accessed.

It is conceivable that a 16-bit processor with banked RAM would likewise have different sizes for near and far data pointers.

Note what the C standard says - as quoted by John Bode. Note, too, that the C standard says nothing about the sizes of pointers to functions at all.

The POSIX standard lays down some extra requirements:

> 2.12.3 Pointer Types > >All function pointer types shall have the same representation as the type pointer to void. Conversion of a function pointer to void * shall not alter the representation. A void * value resulting from such a conversion can be converted back to the original function pointer type, using an explicit cast, without loss of information. > >Note: The ISO C standard does not require this, but it is required for POSIX conformance.

There is no such guarantee in either C or C++ ISO standards, but in practice, I've yet to see a platform where this doesn't hold.

Note that regardless of this, reinterpret_cast'ing one pointer to another will more often than not lead to U.B., with a few exceptions (void*, and unsigned char* for PODs). So would any union tricks. So the obvious question is: why would you care?

When programming x86 real mode with Watcom C you could have a mixed memory model using 16-bit near pointers and 32 bit far pointers.

In the protected mode DOS days, a function pointer and a data pointer could have different lengths because data could be in a different section.

Generally yes, All pointers to anything, whether they point to a int or a long or a string or an array of strings or a function, point to a single memory address, which is the same size on a machine. That is because the Processer on a machine has a an address register that these pointers are loaded into, and the size of that address register controls the size of the pointers.

The only exception might be in cases like old Intel 8088 16-bit machines where there was a two step process to determine the memory address, involving a 16 bit segment pointer, (which identified a 64K block of memory within the 1MByte address space), and then a second 16 bit memory address to identify the specific memory address within that segment. These two 16 bit addresses were then combined to get the complete 20 bit memory address. In that scenario, then, I imagine it might be possible to distinquiah between the individual 16 bit addresses, and the combined 20-bit address.