Xref: utzoo gnu.gcc:721 gnu.gcc.bug:1207
Path: utzoo!yunexus!telly!attcan!utgpu!watmath!uunet!mcvax!ukc!warwick!jeff
From: jeff@cs.warwick.ac.uk (Jeff Smith)
Newsgroups: gnu.gcc,gnu.gcc.bug
Subject: -2147483648 in gcc
Message-ID: <1918@diamond.warwick.ac.uk>
Date: 7 Jun 89 17:15:12 GMT
Article-I.D.: diamond.1918
Sender: news@warwick.ac.uk
Reply-To: jeff@cs.warwick.ac.uk (Jeff Smith)
Followup-To: gnu.gcc
Organization: Computer Science, Warwick University, UK
Lines: 43

In this article, I want to demonstrate a bug in gnu cpp, and
a possible bug - certainly a nasty - that can easily be
corrected in <limits.h>. I will use this program for discussion:

      #include <limits.h>

      #if N < 0
      main () { printf ((N < 0) ? "good\n" : "bad\n"); }
      #else
      main () { printf ("ugly\n"); }
      #endif


When run through gcc-1.35 with N textually replaced as -2147483647,
-2147483648, -2147483649, this program produces "good\n", "bad"
and "ugly" respectively. I'm interested in the behaviour of the
compiler with N as -2147483648, which is LONG_MIN in gcc's <limits.h>.

ansC does not allow numerical constants to be negative, so the
-2147483648 has to be parsed as NEGATE 2147483648. Now 2147483648
is greater than LONG_MAX in <limits.h>, and is therefore promoted
to unsigned long, so it's subsequent negation will still not
produce a number that is less than zero. The behaviour of the compiler
proper at this point is therefore correct. However the value of
LONG_MIN in <limits.h> is not (assuming <limits.h> is written in the
ansC of the compiler it describes). I think LONG_MIN should
be defined as (-LONG_MAX-1), rather than -2147483648, and
similarly for SCHAR_MIN, CHAR_MIN, SHRT_MIN and INT_MIN. These
definitions would still be appropriate for -traditional use. If
you believe that -traditional mode should also allow the use of
-2147483648 directly, then there are some additional changes to
be made to cc1.

The behaviour of the preprocessor does not seem to be correct.
With the distributed <limits.h>, and the preprocessor and
the compiler proper run on the same machine, N as -2147483648
should produce "ugly\n", and N as (-LONG_MAX-1) should produce
"good\n". It actually produces "bad\n" and "good\n", which is a bug.

--
Jeff Smith
jeff@cs.warwick.ac.uk
mcvax!warwick!jeff