Path: utzoo!attcan!uunet!mcsun!hp4nl!tuegate.tue.nl!eba!tuewsd!wsinpdb From: wsinpdb@lso.win.tue.nl (Paul de Bra) Newsgroups: comp.bugs.sys5 Subject: Re: INT_MIN bug Keywords: negative constants, overflow Message-ID: <1305@tuewsd.win.tue.nl> Date: 20 Jul 90 08:19:38 GMT References: <1295@tuewsd.win.tue.nl> <9007181749.AA16031@mindcrf.mindcraft.com> Sender: news@eba.eb.ele.tue.nl (The News system) Organization: Eindhoven University of Technology, The Netherlands Lines: 33 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 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 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)