Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: What's Wrong here?
Message-ID: <9558@mimsy.UUCP>
Date: Sun, 29-Nov-87 08:33:54 EST
Article-I.D.: mimsy.9558
Posted: Sun Nov 29 08:33:54 1987
Date-Received: Tue, 1-Dec-87 06:04:36 EST
References: <278@westmark.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 34
Xref: mnetor comp.lang.c:5633 comp.sys.ibm.pc:10601

In article <278@westmark.UUCP> dave@westmark.UUCP (Dave Levenson) writes:
>#include 
>main()
>{
>	long n;
>	n = (1 << 31) -1;
>	printf("%ld\n", n);
>}
>
>If I compile this under UNIX, and run it, it prints 2147483647.

(You do not say on which machine---probably one with 32 bit ints.)

>If I compile this under MS-DOS using Microsoft C Rel 3.0, and run
>it, it gets the same answer!!!  But if I compile it under MS-DOS
>using Microsoft C Rel 4.0, it prints 65535.

That is a bit peculiar.  I would expect 1<<31 to be (int)0, then
(int)0-(int)1 to be (int)-1, which should produce (long)-1 when
extended.

>Am I mis-using C?

Yes: use (1L << 31) - 1, or (1 << 31L) - 1, or ((long)1 << 31) -
1, or . . . .  If you shift something too many positions, I believe
the result is officially undefined; this gives MS C license to come
up with anything, including the rather ludicrous 65535, or the more
reasonable -1, or even 2147483647.  (I would be more certain but
my references are at work and I am not.)  At a guess, I would say
that MS C 3.0 noticed the shift count of 31 and put in the (long)s
for you, and that this feature(?) was removed from release 4.0.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris