LLU bad suffix on number

Question

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

Visual studio 2010 (on windows7-64) complains about "bad suffix on number", patching the library to use LL works. Is there some preprocessor definition or properties check box I have to set to enable LLU ?

ps anybody know which is the correct behaviour? I have always assumed that whatever VC++ did was the opposite of the standard - but things have improved recently.

Answer 1

Looking at the standards I have available to me (drafts only, but of reasonably recent versions), both C++ and C define both "ULL" and "LLU" as valid suffixes for an integer literal. This may be a recent change which VS2010 doesn't follow, but I note that VS2012 does the exact same thing (i.e only ULL works).

There is a difference between using a signed and unsigned literal, and that is MSVC's behaviour when you right-shift a signed value. A signed literal will be sign-extended, 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 produce two different values under MSVC.

So if your library is expecting defined behaviour by stipulating unsigned values, then converting them to unsigned values will potentially result in undefined behaviour.

In short, I think MSVC is being a bit naughty in only accepting one form of the suffix, but the best fix is to switch where the 'U' appears, and not to remove it entirely.