Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!crdgw1!camelback!volpe
From: volpe@camelback.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.lang.c
Subject: Re: Interesting Bug in Microsoft C
Message-ID: <17307@crdgw1.crd.ge.com>
Date: 5 Mar 91 13:51:14 GMT
References: <12541@pucc.Princeton.EDU>
Sender: news@crdgw1.crd.ge.com
Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe)
Lines: 24

In article <12541@pucc.Princeton.EDU>, EGNILGES@pucc.Princeton.EDU (Ed
Nilges) writes:
|>A colleague wrote a program containing the value -2,147,483,648L (-2**31)
|>which compiled and ran on Borland Turbo-C but produced a diagnostic "con-
|>stant to long" on Microsoft QuickC.  When he changed it, replacing
|>the value with -2,147,483,647L - 1 the program ran on QuickC.
|>
|>I think what is happening is this.  The compiler is evaluating con-
|>stants in the lexical analysis phase by (in the case of -2**31) not-
|>ing the sign, then grabbing each decimal digit, shifting the old
|>value by multiplying by ten, and adding the next digit to the old
|>value.  This algorithm has a bug.  It generates the value 2**31 which
|>is too large for a long integer.

The compiler is correct. Using the constant "-2147483648L" is a bug
if "2147483648" is too big to fit in a long. C doesn't have negative
constants. It has positive constants preceded by the unary minus operator.
Thus, "-2147483648L" is not a constant, but an integral constant expression
containing a subexpression out of range. The correct way to code for this
value is, as you already noted, "-2147483647L-1".                  
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com