> With proper support from the compiler, it's theoretically possible on > x86-64 systems to use 32-bit pointers in long mode. I'm not aware of any systems that use this, however.
Vxworks does. We just finished doing the gcc port. From a software point of view ILP32 mode on a 64-bit CPU/OS is indistinguishable from regular 32-bit mode. > I'm not sure how big longs are on those systems, but I > wouldn't be surprised if longs are 32-bits or 64-bits and pointers > 128-bits. I really hope not. > > > One from me, if you like... Just don't use the "unsigned long" type. > > > The intptr_t type would be better (it's 32-bit on 32-bit systems and > > > 64-bit on 64-bit systems). > > > > Nice, I didn't know about that. But how is this any different from > > unsigned long? The story behind this is that ISO C89 requires that "long" be at least as big as a pointer (ie. "void *"). The actual requirement is that it be possible to store a pointer in a standard integer type, and "long" is the largest standard integer type. Unfortunately C99 relaxed this requirement, and allowed abominations like the win64 ABI. This means you have a choice: Write standard conforming code (long) that works on all known systems except win64, or use features that do't exist on many systems. IIRC C99 types like intptr_t are not supported on several fairly common unix systems. It's ironic that the one system that requires C99 features explicitly does not (and probably never will) have full C99 support. Paul
