Comments on: Portable Code: How To Check If A Machine Is 32 Bit Or 64 Bit

By: Find The Offset Of An Element In A Structure In C- offsetof() | Safer Code - Secure Coding In C C++ And More..

Tue, 05 May 2009 13:38:34 +0000

[...] above snippet will work, but not always (Hint). Many people use a much simplified form, which does not involve any pointer arithmetic: unsigned [...]

By: unwind

unwind — Mon, 06 Apr 2009 18:29:43 +0000

@Shantanu: Oh, I got 450 ms of Internet fame! Amazing … But I think “the” is stretching it a bit. True though, I did write gentoo (the file manager, for picky people who only associate the word with the Linux distro). Glad you know it!

Btw, I find the backslash in “C \ C++” horrible … I find “C/C++” horrible too; they’re two separate languages, may I humbly suggest the word “and”, to cover both?

By: Zombie No. 5

Zombie No. 5 — Mon, 06 Apr 2009 17:19:46 +0000

I don’t quite get the point of the check in the first place. “64-bit” is most of the time marketing blather. I think even today no 64-bit machine has a true 64-bit address and data bus. They can handle at most 48 to 56-bit and the rest is just zero padded. Also, the C compiler doesn’t have to expose or limit itself to the actual hardware architecture. Consider Java which always emulates a 64-bit environment. A C compiler can use an arbitrary ABI with long being 32 or 64 bit regardless of the CPU. See, long long is already an “emulated” integer type on 32-bit architectures, so, for example, modifying such integers cannot be atomic.
It is also not necessarily a good idea to use 64-bit integers on 64-bit architectures. Many people seem to think it will be automatically faster. No, it wasted bandwidth and memory. Heck, it is even an issue when pointers are 64-bit wide. You rarely need more than 2 GiB address space or memory but you’ll always have the overhead. With code heavy on pointer handling, such as linked lists, hash tables, you get twice as much overhead. So it can actually be faster to use indices and limit them to 32 bit or maybe even 16 bit. Modern CPUs are much faster when they can operate on cached or prefetched data. So while it’s not a problem to use much more memory nowadays, it is still a good idea to keep data compact and local to take as much advantage of memory as possible.

Clean code that isn’t “optimized” to death, rarely needs to know sizes of integers or pointers. You just use the sizeof operator and respect the integers’ extreme values instead of making assumptions. Since the compiler knows these compile-time constants and many optimization techniques, well-written code will be optimized without having to do that manually. For example, a mask operation like “& 0xffffU” will be completely skipped for 16-bit integers but if you write it out, your code will still work with 32-bit or 36-bit integers.

By: Derek Jones

Derek Jones — Wed, 11 Mar 2009 12:11:08 +0000

@Shantanu: The problem with using sizeof is that padding bits/bytes may exist in the type, rendering the result useless. Checking the value of the macros INTPTR_MIN/MAX (in stdint.h) is the only reliable way of obtaining information on the size of pointers.

By: Shantanu Goel

Shantanu Goel — Wed, 11 Mar 2009 11:35:34 +0000

@unwind: Thanks for the input. I will update your and Derek’s suggestions to the post in a short while.
PS: I guess you are “The” Emil (of gentoo)?

By: unwind

unwind — Wed, 11 Mar 2009 08:56:47 +0000

Bleh. The blog engine ate my brackets. Maybe it supports HTML entities? If so, this looks right:
#include
If not, the header to include is limits.h.

By: unwind

unwind — Wed, 11 Mar 2009 08:55:49 +0000

I’d suggest doing
#include

n = CHAR_BIT * sizeof (void *);

To capture word-addressed machines, where CHAR_BIT will be larger than 8. Silently assuming CHAR_BIT is eight is not a good way to write portable code.

By: Shantanu Goel

Shantanu Goel — Wed, 11 Mar 2009 04:59:54 +0000

@Derek: yeah. I just read through the document. So, this approach might have issues on some machines which do not follow the data models listed above. Do you think using an int * would be better than a void * then? (Because word-addressed processors face this different addressing issue only for pointers characters/bytes and void, which is supposed to have a representation identical to characters.) But that also leads me to believe that there wouldn’t be a “true” portable piece to check this across _all_ architectures because even apart from word-addressing, “some” architectures with their own compilers might choose to represent pointers differently. So, we can probably have something that works across the common programming models that one thinks their program would work on (e.g. the ones listed above are the ones that common-workstation processors use)

PS: Your searchable standard and associated commentary is great. I found the statement related to void * representation also on your site.

By: Derek Jones

Derek Jones — Tue, 10 Mar 2009 23:55:49 +0000

Nice try, but this approach will not work on processors that use word addressing, such as the Cray PVP. Many DSPs use word addressing and they get around this problem by defining the character types to be 16 or 32-bits.

Check out the ‘Common implementation’ discussion in: http://c0x.coding-guidelines.com/3.6.pdf