[net.lang.c] expression sequencing bugs

C90630JG%WUVMD.BITNET@wiscvm.ARPA (09/27/86)

In article <760@oakhill.UUCP> tomc@oakhill.UUCP (Tom Cunningham) writes:
>    /* a = b + b + b */
>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>
>I expected the result to be 6.  With the Microsoft C compiler and the
>compiler on the Sun 3, the result is 9.  Apparently the parenthetical
>assignments are all getting done before the comma and addition.  Any
>thoughts on this?
>
Tom, I agree, the result should be 6, as defined by K&R, but I have tried
it on ......................
I would like everyone to test it on as many machines as prossible, to
see if we can find as least ONE other besides Small-C, that works.

Mike Stump  ucbvax!hplabs!csun!csunb!beusemrs

I would like to report that the Computer Innovations C86 C complier
on the IBM-PC produces the correct answer.

Jonathen Goldberg
c90630jg@wuvmd.bitnet

don@umd5 (Chris Sylvain) (10/01/86)

In article <4197@brl-smoke.ARPA> C90630JG%WUVMD.BITNET@wiscvm.ARPA writes:
>In article <760@oakhill.UUCP> tomc@oakhill.UUCP (Tom Cunningham) writes:
>>    /* a = b + b + b */
>>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>
>>I expected the result to be 6.  With the Microsoft C compiler and the
>>compiler on the Sun 3, the result is 9.  Apparently the parenthetical
>>assignments are all getting done before the comma and addition.  Any
>>thoughts on this?
> ........
>I would like everyone to test it on as many machines as prossible, to
>see if we can find as least ONE other besides Small-C, that works.
>Mike Stump  ucbvax!hplabs!csun!csunb!beusemrs
>
The microVAX running Ultrix V1.2 that I am using insists the result
is 9.
Has anyone tested 4.3BSD yet?

-- 
--==---==---==--
.. Long time the manxome foe he sought -- ..

ARPA: don@umd5.UMD.EDU     BITNET: don%umd5@umd2
UUCP: ..!{ seismo!umcp-cs, ihnp4!rlgvax }!cvl!umd5!don

** WARNING: don@mimsy.UMD.EDU is a different person **
** (umcp-cs and mimsy.umd.edu are the same machine) **
**   -->   Please double-check the address   <--    **

6101778@PUCC.BITNET (Angus Christie) (10/03/86)

>>    /* a = b + b + b */
>>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>
 [with various results for a]
>I would like everyone to test it on as many machines as prossible, to
>see if we can find as least ONE other besides Small-C, that works.
 
MIX-C for the IBM-PC also gives an answer of 6 for all three of the
following:
 
     a = ((b=1),b) + ((b=2),b) + (b=3),b);
     a = (b=1) + (b=2) + (b=3);
     a = (b=1), a += (b=2), a += (b=3);
 
Beware, however, that MIX-C accomplishes this by doing absolutely NO
optimization of any sort.  It doesn't fold constants.  It has no register
variables.  Its execution speed, as a result, leaves something to be
desired.  But then again, what do you expect for only $40.

gunnar@hafro.UUCP (Gunnar Stefansson) (10/03/86)

In article <4197@brl-smoke.ARPA> C90630JG%WUVMD.BITNET@wiscvm.ARPA writes:
>In article <760@oakhill.UUCP> tomc@oakhill.UUCP (Tom Cunningham) writes:
>>    /* a = b + b + b */
>>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>
>>I expected the result to be 6.  With the Microsoft C compiler and the
>>compiler on the Sun 3, the result is 9.  Apparently the parenthetical
>>assignments are all getting done before the comma and addition.  Any
>>thoughts on this?
>>
>Tom, I agree, the result should be 6, as defined by K&R, but I have tried
>it on ......................
>I would like everyone to test it on as many machines as prossible, to
>see if we can find as least ONE other besides Small-C, that works.

Just for the record, our HP 9000, Model 550 running HP-UX returns
the value 6. Surely anything else isn't just strange, bizarre,..., but
just plain a compiler bug.

Gunnar

defron@violet.berkeley.edu (Daniel Efron) (10/04/86)

In article <1269@umd5> don@umd5.umd.edu (Chris Sylvain) writes:
>>>    /* a = b + b + b */
>>>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>>
>The microVAX running Ultrix V1.2 that I am using insists the result
>is 9.
>Has anyone tested 4.3BSD yet?

The result is 9 on 4.3BSD.

	       -- Dan Efron

jpierre@mit-eddie.MIT.EDU (John Pierre) (10/06/86)

In article <1269@umd5> don@umd5.umd.edu (Chris Sylvain) writes:
>In article <4197@brl-smoke.ARPA> C90630JG%WUVMD.BITNET@wiscvm.ARPA writes:
>>In article <760@oakhill.UUCP> tomc@oakhill.UUCP (Tom Cunningham) writes:
>>>    /* a = b + b + b */
>>>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>>
>>>I expected the result to be 6.  With the Microsoft C compiler and the
>>>compiler on the Sun 3, the result is 9.  Apparently the parenthetical
>>>assignments are all getting done before the comma and addition.  Any
>>>thoughts on this?
>> ........
>>I would like everyone to test it on as many machines as prossible, to
>>see if we can find as least ONE other besides Small-C, that works.
>>Mike Stump  ucbvax!hplabs!csun!csunb!beusemrs
>>
>The microVAX running Ultrix V1.2 that I am using insists the result
>is 9.
>Has anyone tested 4.3BSD yet?
>

4.3BSD's cc(1) produces a value of 9.

-john pierre  

jhodgson@sjuvax.UUCP (J. Hodgson) (10/10/86)

 I ran the (in)famous 
	a= ((b=1,b)) + ((b=2,b)) + ((b=3,b))
on three different versions of C. I got 6 from MIX.C (for reasons I understand,
it works left to right), 9 from the C that comes in 4.3 BSD, which I also
understand (all the left hand parts first) and 7 (!!) from an early Lattice C.
I can derive two explanations for this and confess that I did not bother to try
the 1,2,4 version that might have shown which was the right one. In any case
I haven't seen 7 claimed yet, so I do it now!