Type of integer literals and ~ in C

Somehow, it looks like the ~ operator already knows that it should act on 64 bits?

It's not the ~ operator, it's the cast. Here is how the integer conversion is done according to the standard:

6.3.1.3 Signed and unsigned integers

• When a value with integer type is converted to another integer type other than _Bool, if the value can be represented by the new type, it is unchanged.
• Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.
• Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

The value of signed int ~0 corresponds to -1 on systems with two's complement representation of negative values. It cannot be represented by an unsigned long long, so the first bullet point does not apply.

The second bullet point does apply: the new type is unsigned, so MAX of unsigned long long is added to -1 once to get the result into the range of unsigned long long. This has the same effect as sign-extending -1 to 64 bits.

0 is of type int, not unsigned int. ~0 will therefore (on machines that use two's complement integer representation, which is all that are in use today) be -1, not 2³² - 1.

Assuming a 64-bit unsigned long long, (unsigned long long) -1 is -1 modulo 2⁶⁴, which is 2⁶⁴ - 1.

0 is an int

~0 is still an int, namely the value -1.

Casting an int to unsigned long long is there merely to match the type that printf expects with the conversion llu.

However, the value of -1 extended an unsigned long long should be 0xffffffff for 4 byte int and 0xffffffffffffffff for 8 byte int.