The Standard specifies that hexadecimal constants like 0x8000 (larger than fits in a signed integer) are unsigned (just like octal constants), whereas decimal constants like 32768 are signed long. (The exact types assume a 16-bit integer and a 32-bit long.) However, in regular C environments both will have the same representation, in binary 1000 0000 0000 0000.
Is a situation possible where this difference really produces a different outcome? In other words, is a situation possible where this difference matters at all?
The Standard specifies that hexadecimal constants like 0x8000 (larger than fits in a signed
Share
Yes, it can matter. If your processor has a 16-bit
intand a 32-bitlongtype, 32768 has the typelong(since 32767 is the largest positive value fitting in a signed 16-bitint), whereas 0x8000 (since it is also considered forunsigned int) still fits in a 16-bitunsigned int.Now consider the following program:
When 32768 is considered
long, the negation will invert 32 bits,resulting in a representation 0xFFFF7FFF with type
long; the cast issuperfluous.
When 0x8000 is considered
unsigned int, the negation will invert16 bits, resulting in a representation 0x7FFF with type
unsigned int;the cast will then zero-extend to a
longvalue of 0x00007FFF.Look at H&S5, section 2.7.1 page 24ff.
It is best to augment the constants with
U,ULorLas appropriate.