Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!nike!ll-xn!adelie!axiom!linus!philabs!mcnc!ecsvax!bet
From: bet@ecsvax.UUCP (Bennett E. Todd III)
Newsgroups: net.lang.c
Subject: Re: Re: Expression sequencing query
Message-ID: <2076@ecsvax.UUCP>
Date: Mon, 29-Sep-86 14:02:07 EDT
Article-I.D.: ecsvax.2076
Posted: Mon Sep 29 14:02:07 1986
Date-Received: Fri, 3-Oct-86 08:32:53 EDT
References: <760@oakhill.UUCP> <111@titan.UUCP> <353@cullvax.UUCP>
Reply-To: bet@ecsvax.UUCP (Bennett E. Todd III)
Distribution: net
Organization: Duke University Computation Center
Lines: 29

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