Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!ucsd!helios.ee.lbl.gov!nosc!crash!pro-sol.cts.com!jholt
From: jholt@pro-sol.cts.com (joe holt)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW C 3.1 vs 3.0
Message-ID: <2597@crash.cts.com>
Date: 9 May 90 17:16:02 GMT
Sender: root@crash.cts.com
Lines: 17
X-Local-Date: 9 May 90 10:16:02 PDT

In-Reply-To: message from allanh@netcom.UUCP

The way I read K&R, it sounds like MPW 3.0 did things the right way.  ANSI C
says that if a hexadecimal constant is suffixed with 'l' or 'L', then its type
is long int or unsigned long int.  The compiler is supposed to try to fit the
constant into long int first, then unsigned long int if it doesn't fit.  The
constant 0xF0000000L would not fit into a long int, and so its type becomes
unsigned long int (it is legal to have the constant -0x7FFFFFFF, for example).

ANSI C also says you can stick a 'u' or 'U' suffix to force the integer
constant unsigned.

To be safe, I'd stay away from depending on the sign of ambiguous integer
constants.  Until everyone adopts ANSI C, it's going to be a compiler
dependency.

joe holt