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