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