Specifying 64-bit unsigned integer literals on 64-bit data models

Question

As there are various types of 64-bit data models (LLP64/IL32P64, LP64/I32LP64, ILP64, SILP64), what is the standard conforming way of specifying 64-bit unsigned integer literals?

Would specifying the suffix of ULL be sufficient? Or would I end up causing the literal to be interpreted as 128-bit on some data models?

Solution 1

You should use <cstdint> / <stdint.h>, if you have it. This will give you:

• uint64_t is an unsigned integer type which is 64 bits in size
• UINT64_C() is a macro for creating constants of the type uint64_t, by having the macro append the proper suffix.

Solution 2

For the most part, it doesn't matter. If you don't give it a suffix, the type of an integer literal is determined by its value. If the compiler has a 32-bit unsigned long and a 64-bit unsigned long long, an unsigned value that is too large to fit in an unsigned long but not too large for an unsigned long long will have type unsigned long long.

Solution 3

To my knowledge, there is no way to suffix an integer literal to a specific bit width; your only options are l, ul, ll, and ull.

If you are paranoid about it, you would have to wrap your literals in an #if checking for the sizes of long / long long.

Then again, as KennyTM pointed out above, as long as your literals are in the 64bit range and assigned to a 64bit value, it does not matter much if the literal itself is 64 or 128 bit, or does it?

Solution 4

C and C++ don't have standardized 32/64/128 bit variable types. A long, for example, on some systems is 32 bits and 64 on others. It's annoying, but most OSes do provide some better typedefs to help you with, such as uint32, etc, so you con select an exact type that you need.

This is the job of a good configure script: to determine what the system provides, test that it works, and help you select the right type for the right architecture you're running on.

View more solutions