🚀 go-pugleaf

In article <9007181749.AA16031@mindcrf.mindcraft.com> karish@mindcrf.UUCP writes:
>In article <1295@tuewsd.win.tue.nl> wsinpdb@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@research.att.com)