On 13/10/15 12:26, Nathan Scott wrote:
Hi Ken,
...
Isn't strtoull always the right thing to use to end up with 64-bit?
Well today in x86_64 land, sizeof(long) == sizeof(long long) ==
sizeof(int64_t). But I remember when "long" changed from 16 to 32 bits,
and then from 32 to 64 ... and I suspect it may already be 128 on some
platforms (or will be so before I die).
Usually our int64_t use is a result of some api or archive format
constraint, so I was just hoping to make this obvious in the code that
we're not relying on this week's definition of "long long" to make the
code work.
Not really following the need for those macros there. (return value
can always be down-cast for atomvalue.ul vs atomvalue.ull no?)
True ... the cast will produce an acceptable value, but maybe the wrong
one. Consider if long long was indeed 128 bits, then a very, very large
value would get correctly converted in strtoll() and then silently
truncated in the cast. But if we're expecting a 64-bit value and
strtol() returns a 64-bit value, then the very, very large value would
only be partly consumed in strtol() and the code would have a chance of
detecting the error based on *endp not being '\0' after the strtol() call.
Independent of using strtoint64 or strtoll, I need to audit all the code ...
|