Path: utzoo!attcan!uunet!munnari.oz.au!uhccux!ames!apple!oracle!news From: gstein@oracle.com Newsgroups: comp.sys.mac.programmer Subject: Re: THINK C bug (possible explanation of why it exists) Message-ID: <1990Feb7.225358.1125@oracle.com> Date: 7 Feb 90 22:53:58 GMT Sender: news@oracle.com Reply-To: gstein@oracle.com () Organization: Oracle Corporation, Belmont, CA Lines: 49 Jeff Kuskin writes: >In article <6661@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) writes: >>I'm using THINK C 4.0 and it won't accept the constant -2147483648 but it >>does accept -2147483647 and 2147483647. This value does fit in a long. >>Curiously, it does accept 0x80000000 and -2147483647 - 1. >> >>Isn't this a bug or am I going to be called bunky? > >Have a look at the manual, page 457, under the "constant too large" >error message explanation. Evidentally, all integer constants must >have an *absoulte value* less than or equal to (2^31) - 1. > >-- Jeff Kuskin, Dartmouth College > 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. Since it recognizes the number as a distinct value, it thinks you're trying to give it a positive number that is too large. Regarding the hexadecimal number, it probably does not do any range checking while it converts the text into an actual number. The subtraction is legal because Think C probably doesn't do any range checking as it optimizes constant expressions. 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. The compiler will gobble up the unary minus before it reaches the constant (cuz it doesn't know that it will be applied to a constant). Once it hits the constant, it would be kind of difficult to back up and see if the previous token was a negative sign and to allow for that extra little bit of range. So, I don't think you'll be getting called "bunky," whatever that is. I doubt that the compiler will change to fix this "bug," though. It usually doesn't occur, anyhow, cuz writing the numeric representation is not as self-documenting as 0x8000000 (which tells the programmer that the MSB is set). Or, if the number is to be used as a range, you would use LONG_MIN (or whatever the #define is from ). Greg Stein -- This posting bears no relation to my employer Arpa: gstein%oracle.uucp@apple.com UUCP: ..!{uunet,apple}!oracle!gstein