🚀 go-pugleaf

In article <353@cullvax.UUCP> drw@cullvax.UUCP (Dale Worley) 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.
>
>Dec VAX Ultrix gives 9.
>
>Lattice C 3.00 for MS-DOS gives 7!!!  (Yes, that's "7", not a typo!)

Microsoft C 3.0 small memory model gives 6 and DeSmet C 2.51 small
memory model gives 7.

Looks like this falls in the "don't count on the order of evaluation of
subexpressions with side-effects" bucket, even though it doesn't look
illegal.

Certainly, anything that produces widely different answers under
different popular implementations of C should be avoided; it is all well
and good to try to say "such and so is RIGHT, and anything that does
different is wrong" but that doesn't help portability.

-Bennett
-- 

Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet