unsigned long long resTestBad = 0xffffffff + 1; print 0 with %llu, but unsigned long long resA = 4294967295 + 1; print 4294967296 with %llu

Question

It seems that I found a bug when print value of (0xffffffff + 1) with %llu is 0, see below code:

unsigned long long resTestBad = 0xffffffff + 1;  // number of f is 8
printf("resTestBad is %llu, sizeof(unsigned long long) is %ld\n", resTestBad, sizeof(unsigned long long));

will output:

resTestBad is 0, sizeof(unsigned long long) is 8

I think that output is wrong, it should be output or say correct output:

resTestBad is 4294967296, sizeof(unsigned long long) is 8

And

unsigned long long resA = 4294967295 + 1; 
printf("resA is %llu, sizeof(unsigned long long) is %zu\n", resA, sizeof(unsigned long long));

will output:

resA is 4294967296, sizeof(unsigned long long) is 8

But below code is no problem:

unsigned long long resTestAgain = 0xfffffffff + 1;   // number of f is 9
printf("resTestAgain is %llu, sizeof(unsigned long long) is %zu\n", resTestAgain, sizeof(unsigned long long));

It will output(I think it right):

resTestAgain is 68719476736, sizeof(unsigned long long) is 8

My .c file is below:

#include <stdio.h>
#include <limits.h>

int main(void)
{
    int s = 0xfffe;
    printf("s is %d\n", s);

    unsigned int ww = 0xfffe;
    printf("ww is %d\n", ww);

    unsigned long long resTestOk = 0xfffffffe + 1; 
    printf("resTestOk is %llu, sizeof(unsigned long long) is %zu\n", resTestOk, sizeof(unsigned long long));

    unsigned long long resTestBad = 0xffffffff + 1;  
    printf("resTestBad is %llu, sizeof(unsigned long long) is %zu\n", resTestBad, sizeof(unsigned long long));

    unsigned long long resTestAgain = 0xfffffffff + 1; 
    printf("resTestAgain is %llu, sizeof(unsigned long long) is %zu\n", resTestAgain, sizeof(unsigned long long));

    unsigned long long resA = 4294967295 + 1; 
    printf("resA is %llu, sizeof(unsigned long long) is %zu\n", resA, sizeof(unsigned long long));

    unsigned long long resTestUUU = 0xffffffffffffff + 1; 
    printf("resTestUUU is %llu, sizeof(unsigned long long) is %zu\n", resTestUUU, sizeof(unsigned long long));

    unsigned long long resH = (0xffffffff+1) / 1024 / 1024 / 1024;
    printf("%llu\n", resH);

    unsigned long long resD = (4294967296) / 1024 / 1024 / 1024;
    printf("%llu\n", resD);

    return 0;
}

Run it will output:

s is 65534
ww is 65534
resTestOk is 4294967295, sizeof(unsigned long long) is 8
resTestBad is 0, sizeof(unsigned long long) is 8
resTestAgain is 68719476736, sizeof(unsigned long long) is 8
resA is 4294967296, sizeof(unsigned long long) is 8
resTestUUU is 72057594037927936, sizeof(unsigned long long) is 8
0
4

May be you don't believe that, I also don't believe, so I record a video that for prove I said.

See https://imgur.com/a/RAQVPxS

Is it a Bug of CPU or bug of VMWare Workstation? How can I solve it?

Update

Sorry, may be my question is not clear, or say confusion for people.

Problem origin from that I want to test how many memory a 32-bit computer can access(I know it is 4GB, address from 0x00000000 to 0xffffffff, total number is 0xffffffff + 1, unit is bytes, so (0xffffffff + 1) / 1024 /1024 / 1024 = 4GB), so I use below code:

unsigned long long resH = (0xffffffff + 1) / 1024 / 1024 / 1024;
printf("%llu\n", resH);

But it output number 0, that is not what I want to get. I except output is 4. So I also use below code:

unsigned long long resQ = (4294967295 + 1) / 1024 / 1024 / 1024;
printf("%llu\n", resQ);

It output 4 that what is I except. So I want to find out what reason result to different of result.

Then I use below code:

unsigned long long resTestBad = 0xffffffff + 1; 
printf("resTestBad is %llu, sizeof(unsigned long long) is %zu\n", resTestBad, sizeof(unsigned long long));

it output:

resTestBad is 0, sizeof(unsigned long long) is 8

That not is my except, so I test below code:

unsigned long long resTestAgain = 0xfffffffff + 1; 
printf("resTestAgain is %llu, sizeof(unsigned long long) is %zu\n", resTestAgain, sizeof(unsigned long long));

it output:

resTestAgain is 68719476736, sizeof(unsigned long long) is 8

as below code:

unsigned long long resA = 4294967295 + 1; 
printf("resA is %llu, sizeof(unsigned long long) is %zu\n", resA, sizeof(unsigned long long));

it output:

resA is 4294967296, sizeof(unsigned long long) is 8

By see answer, now I understand why 0xffffffff + 1 output 0.

But now I can't understand that value size of 0xffffffff and 4294967295 is the same, why 0xffffffff as unsigned int type(occupy 32-bit), however 4294967295 may be as long or long long or other type(occupy 64-bit).

Answer 1

As explained in @rici’s answer to another question (about C++, but the same rule applies to C), unsigned types are candidates for hex integer literals. 0xffffffff fits in a 32-bit unsigned int or unsigned long, so one of those is its type. Then the int 1 is converted to unsigned long/int for the addition, which overflows. Finally, the unsigned long/int 0 is converted to unsigned long long to become the initial value for resTestBad.

Use 0xffffffffULL to force the literal to be unsigned long long from the get go.

(When you add another f, the value no longer fits in an unsigned long, so the literal already has type long long and it works.)

Answer 2

This answer assumes int to be 32 bits (which is the most common size)

Is it a Bug of CPU or bug of VMWare Workstation?

No, it not a bug. It's how the C standard says it has to be done.

When doing

unsigned long long resTestBad = 0xffffffff + 1;

the first step is to calculate

0xffffffff + 1;

To do that the compiler needs to ensure the the operands at both side of + has the same type. So first it needs to figure out the types.

0xffffffff 

is in decimal the value 4294967295 which can't be stored in a 32 bit signed value. However, it can be stored in a 32 bit unsigned value, and was written in hex in the source. (As @Lundin's answer points out, 4294967295 in the source will only pick signed types, unlike hex literals not considering unsigned int as a possibility. So it will be a 64-bit signed type, either long or long long depending on whether long is 64 of 32-bit. You can check this yourself by printing sizeof(4294967295) vs. sizeof(0xffffffff).

1 has type int, which can be implicitly converted to unsigned int, so the compiler selects 32-bit unsigned for the calculation.

So the calculation is done as:

(unsigned int)0xffffffff + (unsigned int)1;

This gives (a well defined) overflow to the final result zero.

So

unsigned long long resTestBad = 0xffffffff + 1;

is really the same as

unsigned long long resTestBad = (unsigned int)0;

And notice, the type on the Left Hand Side of the = has absolutely no impact on the calculation of the Right Hand Side. No matter if you write unsigned long long resTestBad or float resTestBad or double resTestBad, the calculation on the Right Hand Side is the same. It will always be:

SomeType resTestBad = (unsigned int)0;

BTW: Try this:

float f = 5/2;

Will you get 2.5 because you have float on the Left Hand Side? No, the division is still an integer division so the result is (int)2.

When you use 9 f instead of 8 f, the value can no longer be saved in a 32 bit type so the compiler selects a 64 bit type for the calculation. Consequently, there won't be an overflow.

How can I solve it?

By forcing the Right Hand Side calculation to be done in 64 bit. For instance:

0xffffffffULL + 1

Answer 3

• Everything in C has a type, including these things: 1 which are known as integer constants.
• Normally an integer constant has type int. Or unless it is too large to fit in an int, it has type long, or otherwise if still not large enough, long long. In all these cases it is a signed type.
• Hex (and octal) integer constants are special. In case a hex integer constant can't fit in an int, it will become unsigned int, or if it can't fit in one either, then long, then unsigned long and so on.

So on a 32 bit int system, then 0xffffffff will get type unsigned int and 1 will get type int. Neither which is a type large enough to store the result of 0xffffffff + 1 so we already found the bug here.

Now as it happens, if you have one operand of type unsigned int and one of signed int, an implicit conversion (the usual arithmetic conversions) converts the signed type to unsigned. Details here: Implicit type promotion rules

Therefore both operands end up unsigned int and the result of the addition will also be unsigned int. The result of (unsigned int)0xffffffff + (unsigned int)1 is well-defined in C, on a 32 bit int system we will get a wrap-around and the result is 0.

What types you use in the rest of the program from there doesn't really matter because the result is already calculated.

Conclusion: which type that any operation in C is carried out as, has everything to do with the operands of the given operator and nothing to do with some left operand of assignment where the result will be stored later.

For the same reason as if you write down 1+1=2 on a paper and then store that paper in a folder, the equation on the paper does not magically change depending on what type of folder you store it in - it has already been carried out.

Answer 4

For starters it is much better to use the conversion specifier %zu to output values of the type size_t instead of %ld as you are doing:

 printf("resTestOk is %llu, sizeof(unsigned long long) is %ld\n", resTestOk, sizeof(unsigned long long));

Firstly though the type size_t in general represents an alias for the type unsigned long however according to the C Standard (7.19 Common definitions <stddef.h>)

4 The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.

It seems in your system size_t is indeed an alias for the type unsigned long and outputted values can be represented in objects of the signed type long int.

Now let's consider for example this declaration:

unsigned long long resTestBad = 0xffffffff + 1; 

The unsigned hexadecimal constant 0xffffffff can be represented in an object of the type unsigned int. So it has the type unsigned int. Thus in this expression:

0xffffffff + 1

there is used the arithmetic for objects of the type unsigned int (the integer constant 1 is also converted to the type unsigned int due to usual arithmetic conversions).

As a result there is an overflow because the result can not be represented in an object of the type unsigned int. And the value of the expression is 0.

The same situation takes place in this code snippet:

unsigned long long resH = (0xffffffff+1) / 1024 / 1024 / 1024;
printf("%llu\n", resH);

where the expression 0xffffffff+1 of the type unsigned int produces an overflow for objects of that type and yields 0.

As for this declaration:

unsigned long long resTestAgain = 0xfffffffff + 1; 

then the hexadecimal constant 0xfffffffff can not be represented in an object of the type unsigned int (provided that sizeof( unsigned int ) is not greater than 4). If sizeof( long int ) is equal to 8 or if it is equal to 4 but sizeof( long long int ) equal to 8 (and in your program it indeed is equal to 8) then the constant can be represented in an object of the type either long int. or long long int.

So in this expression:

0xfffffffff + 1

there is used the arithmetic for objects of the type long int or long long int. And the result of the expression can be also represented in an object of that type.

As for this code snippet:

unsigned long long resA = 4294967295 + 1; 
printf("resA is %llu, sizeof(unsigned long long) is %ld\n", resA, sizeof(unsigned long long));

then the constant 4294967295 is greater than the value of INT_MAX equal to 2147483647. So it has type long int if sizeof( long int ) is greater than sizeof( int ) or long long int otherwise. And the result of the expression 4294967295 + 1 can be represented n object of that type as a positive value.

Pay attention to the following quote from the C Standard (6.4.4.1 Integer constants) relative to types of integer constants

5 The type of an integer constant is the first of the corresponding list in which its value can be represented.

                            Octal or Hexadecimal
Suffix     Decimal Constant            Constant
===============================================================
none             int                     int
                 long int                unsigned int
                 long long int           long int
                                         unsigned long int
                                         long long int
                                         unsigned long long int
================================================================
u or U           unsigned int            unsigned int
                 unsigned long int       unsigned long int
                 unsigned long long int  unsigned long long int
================================================================  
l or L           long int                long int
                 long long int           unsigned long int
                                         long long int
                                         unsigned long long int
================================================================
ll or LL         long long int           long long int
                                         unsigned long long int
================================================================  
Both u or U      unsigned long long int  unsigned long long int
and ll or LL
=================================================================