INT_MIN bug

[Paul de Bra]

In article <9007181749.AA16031 at mindcrf.mindcraft.com> karish at mindcrf.UUCP writes:
>In article <1295 at tuewsd.win.tue.nl> wsinpdb at lso.win.tue.nl (Paul de Bra) writes:
>>In sVr3.2 (on the 386) the file <limits.h> contains the definitions
>>#define INT_MIN 	-2147483648
>>and
>>#define LONG_MIN	-2147483648L
>>
>>which, according to K&R (second edition) are unsigned (constant) expressions
>>in ANSI C.
>
>K&R II, section B11, does not say that the values must be unsigned.
>
>The C Standard specifically requires that they have the appropriate signs:
>...

OK, I guess I should have explained the bug more carefully:

-2147483648 is not a numerical constant but a (constant) expression involving
a unary minus sign and a numerical constant 2147483648.
That numerical constant is greater than LONG_MAX so it is an unsigned long.
K&R (second edition, p204) says that 'an integral operand undergoes integral
promotion' (does nothing here since the operand is already unsigned long)
and 'The type of the result is the type of the promoted operand'
which means -2147483648 is an unsigned long.

This means that the values for INT_MIN and LONG_MIN in <limits.h>
on AT&T System V release 3.2 are unsigned long (hence certainly not negative).

The AT&T cc compiler happens to treat INT_MIN and LONG_MIN as negative,
but gcc certainly doesn't and neither should any ansi-c compiler.

Paul.
(debra at research.att.com)