Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!hplabs!gatech!emory!platt From: platt@emory.uucp (Dan Platt) Newsgroups: comp.lang.c,comp.sys.ibm.pc Subject: Re: What's Wrong here? Message-ID: <2356@emory.uucp> Date: Sun, 29-Nov-87 00:44:44 EST Article-I.D.: emory.2356 Posted: Sun Nov 29 00:44:44 1987 Date-Received: Tue, 1-Dec-87 05:43:27 EST References: <278@westmark.UUCP> Reply-To: platt@emory.UUCP (Dan Platt) Organization: Emory University Lines: 36 Xref: mnetor comp.lang.c:5630 comp.sys.ibm.pc:10595 In article <278@westmark.UUCP> dave@westmark.UUCP (Dave Levenson) writes: >Perhaps a C guru on the net can tell me what's wrong with this >trivial C program? > >#include>main() >{ > long n; > n = (1 << 31) -1; > printf("%ld\n", n); >} > > >Am I mis-using C? Is there a reason why the expression is >apparently evaluated as an int and then promoted to long in one >compiler but evaluated as a long in two others? I don't know if it's a mis-use. It would seem that there is some ambiguity over the issue if not all compilers treat this the same. It seems to me that most of the compilers that I've tried (on the Sun the DEC, and TurboC) treat this as the long answer. Yet I don't see any reason why it should. I would say that to make absolutely sure, you should code this as #include main() { long n; n = (1L << 31) - 1; printf("%ld\n",n); } and see if this fixes the problem. If it doesn't then there's a bug in MSC4.0 (which they may or may not have fixed by 5.0). Dan Platt