Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!hpcnoe!jason
From: jason@hpcnoe.UUCP (Jason Zions)
Newsgroups: net.lang.c
Subject: Re: Expression sequencing query
Message-ID: <790004@hpcnoe.UUCP>
Date: Sat, 27-Sep-86 20:29:31 EDT
Article-I.D.: hpcnoe.790004
Posted: Sat Sep 27 20:29:31 1986
Date-Received: Thu, 2-Oct-86 20:50:41 EDT
References: <760@oakhill.UUCP>
Organization: HP Colorado Networks Division
Lines: 40

Dale Worley (drw@cullvax.UUCP) writes:

    Harbison&Steele (7.11) makes it clear that an implementation must
    evaluate one argument of a binary operator completely before starting
    evaluation of the other argument.  Thus, the result should be 6.  I
    don't know what the ANSI standard says.

Unfortunately, he didn't read far enough into section 7.11, or he would have
seen the following passage:

    The original description of C specified that subexpressions may be
    evaluated in any order ... The matter of interleaving was not
    discussed... We advise implementors to adhere rigidly to the
    restrictions outlined here...

In this passage, H&S state very clearly that the restriction on interleaving
is one they have added, and that the restriction did not exist in prior
implementations.

In short, a C compiler implemented under K&R rules does indeed permit side-
effect evaluation in any order. Pure PCC-based compilers belong in this class.
I personally agree with H&S; it's an ugly thing to do. Of course, H&S also
say:
	We also advise programmers not to exploit these restrictions too
	heavily...

which I would contend the original example does. As I have said before, people
who use more than one side-effect on the same variable in a single statement
deserve everything they get.

Could one of the true C wizards (I'm still in training, sort of...) come up
with a general statement of "things to avoid doing" to keep from getting
bitten by this interleaving bug? The statement I make in the previous para-
graph is a first cut, but I recognize that it is both too restrictive and
insufficiently restrictive to avoid the problem.
--
Jason Zions				Hewlett-Packard
Colorado Networks Division		3404 E. Harmony Road
Mail Stop 102				Ft. Collins, CO  80525
	{ihnp4,seismo,hplabs,gatech}!hpfcdc!hpcnoe!jason