Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!esmeralda.access.net.au!news.netspace.net.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!psgrain!iafrica.com!uct.uni.net.za!ru.uni.net.za!wits.uni.net.za!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!arclight.uoregon.edu!news.bc.net!unixg.ubc.ca!noc.van.hookup.net!vertex.tor.hookup.net!nic.wat.hookup.net!news
From: schaffer@wat.hookup.net
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Compiler bug?
Date: 7 Nov 1996 18:17:14 GMT
Organization: HookUp Communication Corporation, Waterloo, Ontario, CANADA
Lines: 58
Message-ID: <55t93a$tib@nic.wat.hookup.net>
References: <55p7ck$r2l@csgrad.cs.vt.edu> <3280F04E.4D5A@cococo.net>
Reply-To: schaffer@wat.hookup.net
NNTP-Posting-Host: schaffer.wat.hookup.net
X-Newsreader: IBM NewsReader/2 v1.2
In <3280F04E.4D5A@cococo.net>, Kelley <kelley@cococo.net> writes:
>Tommy Johnson wrote:
>>
>> This program doesn't work as I think it should. On line 10, b is not
>> incremented between the first and second b++'s, though it is correct
>> after the entire expression.
>>
>> On FreeBSD 2.2-Current as of about Oct 13, the program below produces
>> 0x1212 instead of 0x3412 (gcc 2.7.2.1, or gcc 2.6.3). It also happens
>> on NetBSD 1.1B as of about May 16 on an HP300 (gcc 2.7.2). It DOES produce
>> 0x3412 on a DEC alpha with gcc 2.7.2, or gcc 2.7.2 on a DECstation
>> (OSF1 3.2 148, and Ultrix 4.4 rev 69 respectively).
>>
>> (It also breaks on FreeBSD 2.1.5-Release with gcc 2.6.3)
>>
>> Am I hallucinating? TIA...
>>
>> -Tom "Bugger, now I have to wait for someone to wake up." -Marcus
>> tjohnson@csgrad.cs.vt.edu "My other computer ALSO runs unix." -me <*>
>> http://csgrad.cs.vt.edu/~tjohnson/ Commercial email is unwelcome.
>> Message and signature (c) 1996 Tommy O. Johnson, all rights reserved
>>
>> --- Bite Here --- Bite Here --- Bite Here ---
>>
>> /* Copyright: test program, do with it as you wish
>> ** Tommy Johnson
>> */
>> main()
>> {
>> int a,b;
>> unsigned char c[2];
>>
>> b=0;
>> c[0]=0x12;
>> c[1]=0x34;
>>
>> a=c[b++]|((c[b++])<<8);
>> printf("should be 0x3412 %4x\n",a);
>> }
>
>Not sure if it is a bug or not, since the expression (to the best of my
>recollection) with a post increment operator isn't evaluated until the
>next expression, but try this out on line 10:
>
>a=c[--b] | ((c[++b])<<8);
>
>Very interesting since it is the same variable, but I can tell you that
>the Borland C++ 4.5 (on Windoze95)compiler evaluates to 0x1212 also.
>
>Later
>Kelley
It isn't a bug. The C standard leaves the order of expression evaluation
explicitely unspecified, and it is a mistake to rely on a specific order
of evaluation.
Hartmann Schaffer