assigning a value to a long long integers using gcc on sparc solaris

Question

I came across something that I think rather strange. The test program

int main(int argc, char* argv[])
{
    cout<<"hello"<<endl;
    long unsigned l = 0x12345678;
    long long unsigned ll =  0x12345678;
    cout<<sizeof(l)<<endl;
    cout<<sizeof(ll)<<endl;
};

output is:

hello    
4    
8

No surprises there. The long int has a size of 4 bytes and the long long has a size of 8 bytes. However, when I change it so that the long long is assigned

long long unsigned ll =  0x123456789;

at compile time I get

error: integer constant is too large for "long" type

Now this same test does compile if I force a 64 bit build using the option -m64. Am I doing something wrong or is this a bug in GCC?

Answer 1

Change that to

long long unsigned ll = 0x123456789ULL; // notice the suffix

Without the suffix, the literal is bigger than the maximum unsigned long value on your machine, and that, according to C++03 (but not C++11, which has long long), is undefined behavior. This means that anything can happen, including a compile-time error.

It's also worth nothing that there's no long long in C++03, so it's not guaranteed to work, you're relying on an extension. You'd probably better be off using C++11 instead.

Answer 2

The thing here is that many people seem to look at a line of code like your:

unsigned long long ll = 0x123456789;   /* ANTI-PATTERN! Don't do this! */

and reason "oh, the type is unsigned long long, so the value is unsigned long long and it gets assigned", but that's just not how C works. Literals have their own type, that doesn't depend on the context in which they're being used. And the type of integer literals is int.

This is the same fallacy as when folks do:

const double one_third = 1 / 3;   /* ANTI-PATTERN! Don't do this! */

Thinking "the type on the left is double, so this should assign 0.3333333...". That's just (again!) not how C works. The types of the literals being divided is still int, so the right hand side evaluates to exactly 0, which is then converted to double and stored in the one_third variable.

For some reason, this behavior is deeply non-intuitive to many people, which is why there are many variants of the same question.