size_t is pointer size in practice

Question

Let me first clarify that I am by now very familiar with definitions of size_t and intptr_t, and I don't want any repetitions of what they accomplish.

Instead I would like to know the following. Do you know of any platform, except x86/DOS (with its unbearable memory models) where the cast

void* a = ...;
size_t b = (size_t)a;

actually loses bits or bytes?

Thanks!

Tchao

why would you ever cast a pointer to size_t??? – Forwent

As a side note, I can't even begin to imagine where such question might come from. Why would you ever want to do such a cast? Size of 'size_t' and size of pointer are completely unrelated, so it is naturally to assume that such platforms exist in general case, regardless of whether they exist in reality. – Bakst

It may not be good practice to assume that the size of size_t and the size of pointers are the same and no new code should be written with that assumption, I can see where a question like this might come from: legacy code. I imagine that there's a lot of code out there that makes exactly this assumption. Just like there's a lot of code that assumes an int or a long is 32 bits (no more, no less - that's why MS chose the LLP64 model for Win64). Someone (maybe even Jonas) might want to determine whether it's worthwhile to expend time & effort into proactively changing the legacy code. – Irresistible

@MitchWheat I've asked the same question: programmers.stackexchange.com/questions/294761/… – Hannon

Answer 1

AFAIK, on AS/400 pointers are 128-bit, but size_t is defined to be 32-bit.

Septilateral

Interesting! What does sizeof(long) yield? – Sedgewick

that seems that long is 64-bit but can't say for sure. – Septilateral

A more important question is: Can you provide an example of where casting a pointer to size_t is valid code? – Forwent

It is always valid to cast a pointer to size_t. What you can validly do with the result is another question. – Palm

Such compilers are non-compliant. This answer proves that non-compliant compilers exist. (It was caused by the compiler pre-dating the addition of size_t into the standard) – Altitude

It is not compiler's defect, it's feature of hardware/OS compiler has to match. Standard doesn't dictate The very raison d'être of intptr_t type is the fact that pointer size might be not connected with any of other types, thus storing it in 'normal' integer variable is impossible. Cf. in (theoretic) C99 compiler for x86 real mode intptr_t would be 32bit (to store far ptr), but size_t would be 16bit, because contiguous memory area size is limited to one segment. – Septilateral

why is the pointer size so large? 64 bits seem to be more than enough – Bullroarer

@LưuVĩnhPhúc from Wikipedia: This was the original design feature of the System/38 (S/38) in the mid 1970s planning for future use of faster processors, memory and an expanded address space. When at a point in the future 128-bit general purpose processors would appear, IBM i will already be fully 128-bit enabled. For 64-bit PowerPC processors, the virtual address resides in the rightmost 64 bits of a pointer. The 64-bit address space references main memory and disk as a single address set which is the single-level storage concept. – Grigri