LLU bad suffix by number

Question

I have a library that uses LLU as a suffix for uint64 literal.

Visual studio 2010 (on windows7-64) complains about a "bad number suffix", the fix library for using LL works. Is there any parameter for the definition or properties of the preprocessor that I have to set to enable LLU ?

ps does anyone know what the correct behavior is? I always assumed that everything VC ++ did was the opposite of the standard, but the situation has improved lately.

Answer 1

Looking at the standards that are available to me (only for drafts, but from fairly recent versions), both C ++ and C define both "ULL" and "LLU" as valid suffixes for an integer literal. This may be a recent change that VS2010 does not follow, but I note that VS2012 does the same (i.e. only ULL works).

There is a difference between using signed and unsigned literals, and this is the behavior of MSVC when you shift a signed value to the right. A signed literal will be expanded with a character extension, but an unsigned literal will be padded with zero.

In other words, the following contrived example:

 unsigned long long l2 = ~0LL >> 5; unsigned long long l3 = ~0ULL >> 5; 

... will generate two different values ​​in MSVC.

So, if your library expects certain behavior by specifying unsigned values, then converting them to unsigned values ​​will potentially lead to undefined behavior.

In short, I think that MSVC is a little naughty in that it takes only one form of suffix, but the best solution is to switch to where “U” appears, rather than removing it completely.