Depends on if you're using the LP64 model (64-bit Linux, many other *NIX) or the LLP64 model (Win64).
I guess Microsoft decided there was more code written for their system that assumed longs were 32-bit than code that assumed pointers could be stored in (unsigned) longs. For 64-bit MS Windows code, pointers are 64-bit, longs are 32-bit, and long longs are 64-bit. With proper support from the compiler, it's theoretically possible on x86-64 systems to use 32-bit pointers in long mode (16 general purpose 64-bit registers). (There's an instruction prefix that will cause the CPU to perform 32-bit pointer calculations in the 64-bit address space.) I'm not aware of any systems that use this, however. (Getting the speed boost from fewer register spills while not paying the space cost of 64-bit pointers sounds very attractive in many applications, though.) I'm not sure if any of the C standards forbid longs being larger than pointers. There are even more strange beasts out there. I think IBM AS/400 LIC uses 128-bit pointers. (The LIC code gets compiled to native code and appended to the LIC binary the first time the LIC binary is run on a new system, and IBM decided to build a lot of future compatibility into LIC.) 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. In any case, I'm a big fan of using more descriptive types (such as the C99 types) to express yourself more clearly for both the compiler and for other coders. Cheers, -Karl On 6/25/07, Blue Swirl <[EMAIL PROTECTED]> wrote:
On 6/25/07, Michal Schulz <[EMAIL PROTECTED]> wrote:
[snip]
> 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?
