Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!emory!mephisto!prism!fsu!gw.scri.fsu.edu"!"pepke
From: pepke@gw.scri.fsu.edu ("Eric Pepke")
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C bug (possible explanation of why it exists)
Message-ID: <499@fsu.scri.fsu.edu>
Date: 8 Feb 90 18:59:31 GMT
References: <1990Feb7.225358.1125@oracle.com>
Sender: news@fsu.scri.fsu.edu
Organization: "Florida State University"
Lines: 52

In article <1990Feb7.225358.1125@oracle.com> gstein@oracle.com writes:
> I would suspect that Think C does not recognize the "-" sign as a part
> of the number, but instead parses the number as two distinct parts:
> 
> -2147483648  -->  {-}  {2147483648}
> 
> Think C (in a later phase) recognizes the application of the unary
> minus to a constant, performs the negation on the constant, and
> replaces the two tokens (syntax tree nodes) as a single constant.

The general idea of parsing the number and then negating it is a pretty 
common way of doing things, but creating a negative constant should be the 
job of the lexical analyzer, not the parser.  You basically look at the 
sign, parse the number and create the value, and then optionally negate 
the value.  If you don't check for overflow when parsing the number, this 
method works just fine.  Parsing 2147483648 gives you 0x80000000, which 
interpreted as an unsigned long is 2147483648.  Negating this results in 
the same value, 0x80000000, which interpreted as a signed long is 
-2147483648.  No problem.  If you want to check for overflow before doing 
the negation, you have to treat this as a special case.

Even if you do something like -(2147483648) to force the parser rather 
than the lexical analyzer to do the negation, it should still work.  The 
compiler should recognize that 2147483648 is too big to be a signed long 
and therefore should be treated as unsigned.  It should then recognize 
that negation of this particular unsigned long producing a signed long is 
valid.  You're probably right, though--THINK C probably doesn't.

> Whether this is a bug or not, I can't really say.  I can say that Mike
> probably won't fix this any time soon because it is a difficult
> problem from a compiler's standpoint.

No, it's not really difficult; it just requires keeping the appropriate 
special cases in mind.  The biggest negative integer in 2's complement 
notation is a situation that is commonly missed.  Pascal gets around the 
problem by disallowing the biggest negative integer in its syntax.  Back 
in the old days when computers ran on kerosene, I had a Tiny Pascal 
compiler/P-code interpreter on a TRS-80 Model 1.  When I tried printing 
out -32768, it printed a strange set of characters, I think something like 
-(*).  I wondered why, but some years later a routine of mine to print 
numbers had the exact same problem.  It was easy to fix, but it required 
being aware of that special case and special consideration of the boundary 
conditions.

Eric Pepke                                     INTERNET: 
pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute  MFENET:   pepke@fsu
Florida State University                       SPAN:     scri::pepke
Tallahassee, FL 32306-4052                     BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.