Reputation: 4378
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?
Upvotes: 33
Views: 48808
Reputation: 400109
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 sizeUINT64_C()
is a macro for creating constants of the type uint64_t
, by having the macro append the proper suffix.Upvotes: 42
Reputation: 76488
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
.
Upvotes: 2
Reputation: 22272
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.
Upvotes: 0
Reputation: 70381
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?
Upvotes: 2