Detect 64-bits in C using size_t

Question 1

size_t is a data type that is able to represent the size of any object.

64-bits usually refers to the fact that 64 bits are available to address virtual memory. In C, memory is addressed using pointers. As such, sizeof(void*) seems to be more adequate to test for 64-bit environment.

However, this is not guaranteed by the C standard. There might be obscure cases where no safe and reliable way to determine the hardware architecture using C exists.

Because sizeof returns the size as multiples of the size of a char, you might want to look at CHAR_BIT (defined in limits.h) to see how many bits there are in a char.

Question 2

Practically speaking, yes, this is safe and reliable. Platforms you are likely to target or ever target in the future are all byte-addressable, with 8-bit bytes and size_t equal to the machine word length. Most platforms provide guarantees that this will continue to be the case indefinitely (POSIX guarantees this, for example).

Theoretically speaking, no, this is not safe and reliable. Obscure systems like the Cray-1, the PDP-10, and various DSP systems will trip you up. However, consider this: what are the chances that you would ever design software for a Cray-1, which was obsolete before that junior engineer sitting next to you was born?

Question 3

More importantly, is this test safe and reliable under all circumstances, keeping in mind OS and compilers portability ?

There is no "portable way" to do this, because C standard let the environment define SIZE_MAX as large as he wants (as long as it is greater than 65535). But C standard doesn't define what are "32 bits" and "64 bits" platforms neither.

However, on common memory models, size_t is 32 bits on 32 bits platforms and 64 bits on 64 bits platforms.

I'm a bit worried that size_t might only be guaranteed for C99 environments.

size_t is in C89 too. So, as long as your environment is standard, it should define size_t.

Question 4

The real question here is: What are you going to do if neither of sizeof(size_t) == 8 and sizeof(size_t) == 4 is true. You may also, to be sure check that CHAR_BIT == 8 - this avoids confusion if the platform is something other than "commmon, modern hardware", e.g. the Cray-1, PDP-10 mentioned elsewhere.

At some point in the future, I predict that 128-bit machines will exist, but I also guess that this is far into the future, since we are currently only able to use 75% of the available bits in 64-bit machines for memory addresses (size_t relates to memory addressing). Note that the upper 16 bits gives us 65535 times more memory than current limit, so there's a long way to go before we run out of memory space. [Never mind the current cost of building a machine with 256TB of memory, which is the current limit - most systems don't even come near that in DISKSPACE, never mind RAM (rough calculation in my head, but 42 bits is 4TB, so 48 bits should be 32 times more, I think)].

Question 5

CHAR_BIT was already mentioned, and there is the theoretical case that there is additional padding within size_t not used for the value. However, you can safely and portably calculate the exact number of relevant value bits for an unsigned integer type at runtime.

size_t s;
int    num_of_bits;

for (s=1, num_of_bits=0; s!=0; s<<=1, num_of_bits++);

If you need this information at compile time, it may be a good idea to set a #define SIZEOF_BITS 32 to the platform-specific value and verify in your unit tests that it meets the actual num_of_bits. You do have unit tests, right?

Question 6

To check the pointer, this is true, but not in the runtime! Say if you're distributing the source code, it's works. However if you are distributing the binary, it is not reliable. The value is determined during the compile time.