6

My gcc compiler allows me to define an unsigned long long (i.e. 64-bit) literal as

#define A_LITERAL 0x1ull

--- or ---

#define A_LITERAL 0x1llu

Is there any difference between these two literal statements. Is this common to other C compilers?

Mat
  • 202,337
  • 40
  • 393
  • 406
Benjamin Leinweber
  • 2,774
  • 1
  • 24
  • 41
  • 2
    I'm voting this up since it taught me something. I already _knew_ both forms were valid but preferred `ULL` because it matched the `unsigned long long` type. However, it turns out the types are pretty fluid as well, allowing such "weirdness" as `long unsigned long`: see http://stackoverflow.com/questions/17287957/is-long-unsigned-as-valid-as-unsigned-long-in-c – paxdiablo Jun 25 '13 at 02:03

3 Answers3

6

Both are the same: excerpt from n3337 draft of C++11 standard:

integer-suffix:
    unsigned-suffix long-suffix(opt)
    unsigned-suffix long-long-suffix(opt)
    long-suffix unsigned-suffix(opt)
    long-long-suffix unsigned-suffix(opt)

unsigned-suffix: one of
    u U

long-suffix: one of
    l L

long-long-suffix: one of
    ll LL
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
3

Both are allowed by the C standard (section 6.4.4.1).

The unsigned suffix u can be before or after the long l (or long long (ll)) suffix.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
0

ull or llu force the compiler to treat a constant as an unsigned and long long integer.
The order of ll and u doesn't matter, nor their case. you may also write LLU or ULL.

haccks
  • 104,019
  • 25
  • 176
  • 264