Are there any platforms where pointers to different types have different sizes?

The C standard allows pointers to different types to have different sizes, e.g. sizeof(char*) != sizeof(int*) is permitted. It does, however, require that if a pointer is converted to a void* and then converted back to its original type, it must compare as equal to its original value. Therefore, it follows logically that sizeof(void*) >= sizeof(T*) for all types T, correct?

On most common platforms in use today (x86, PPC, ARM, and 64-bit variants, etc.), the size of all pointers equals the native register size (4 or 8 bytes), regardless of the pointed-to type. Are there any esoteric or embedded platforms where pointers to different types might have different sizes? I'm specifically asking about data pointers, although I'd also be interested to know if there are platforms where function pointers have unusual sizes.

I'm definitely not asking about C++'s pointer-to-members and pointer-to-member-functions. Those take on unusual sizes on common platforms, and can even vary within one platform, depending on the properties of the pointer-to class (non-polymorphic, single inheritance, multiple inheritance, virtual inheritance, or incomplete type).

Solution 1:

Answer from the C FAQ:

The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I. Later models used segment 0, offset 0 for null pointers in C, necessitating new instructions such as TCNP (Test C Null Pointer), evidently as a sop to all the extant poorly-written C code which made incorrect assumptions. Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char *'s) than word pointers (int *'s).

The Eclipse MV series from Data General has three architecturally supported pointer formats (word, byte, and bit pointers), two of which are used by C compilers: byte pointers for char * and void *, and word pointers for everything else. For historical reasons during the evolution of the 32-bit MV line from the 16-bit Nova line, word pointers and byte pointers had the offset, indirection, and ring protection bits in different places in the word. Passing a mismatched pointer format to a function resulted in protection faults. Eventually, the MV C compiler added many compatibility options to try to deal with code that had pointer type mismatch errors.

Some Honeywell-Bull mainframes use the bit pattern 06000 for (internal) null pointers.

The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000. It was common on old CDC ones-complement machines to use an all-one-bits word as a special flag for all kinds of data, including invalid addresses.

The old HP 3000 series uses a different addressing scheme for byte addresses than for word addresses; like several of the machines above it therefore uses different representations for char * and void * pointers than for other pointers.

The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair (basically a nonexistent handle) as a C null pointer.

Depending on the ``memory model'' in use, 8086-family processors (PC compatibles) may use 16-bit data pointers and 32-bit function pointers, or vice versa.

Some 64-bit Cray machines represent int * in the lower 48 bits of a word; char * additionally uses some of the upper 16 bits to indicate a byte address within a word.

Additional links: A message from Chris Torek with more details about some of these machines.

Solution 2:

Not quite what you're asking, but back in the 16-bit DOS/Windows days, you did have the distinction between a pointer and a far-pointer, the latter being 32-bits.

I might have the syntax wrong...

int *pInt = malloc(sizeof(int));
int far *fpInt = _fmalloc(sizeof(int));

printf("pInt: %d, fpInt: %d\n", sizeof(pInt), sizeof(fpInt));

Output:

pInt: 2, fpInt 4

Solution 3:

Therefore, it follows logically that sizeof(void*) >= sizeof(T*) for all types T, correct?

That doesn't necessarily follow, since sizeof is about the storage representation, and not all bit-patterns have to be valid values. I think you could write a conformant implementation where sizeof(int*) == 8, sizeof(void*) == 4, but there are no more than 2^32 possible values for an int*. Not sure why you'd want to.

Solution 4:

Back in the golden years of DOS, 8088s and segmented memory, it was common to specify a "memory model" in which e.g. all code would fit into 64k (one segment) but data could span multiple segments; this meant that a function pointer would be 2 bytes, a data pointer, 4 bytes. Not sure if anybody is still programming for machines of that kind, maybe some still survive in embedded uses.

Solution 5:

One could easily imagine a Harvard architecture machine having different sizes for function pointers and all other pointers. Don't know of an example...