Interesting Bug in Microsoft C

[Christopher R Volpe]

In article <12541 at pucc.Princeton.EDU>, EGNILGES at 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 at crd.ge.com