Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: comp.lang.c
Subject: Re: conditional expression evaluation
Message-ID: <3937@utcsri.UUCP>
Date: Fri, 16-Jan-87 11:40:36 EST
Article-I.D.: utcsri.3937
Posted: Fri Jan 16 11:40:36 1987
Date-Received: Fri, 16-Jan-87 23:35:48 EST
References: <2356@brl-adm.ARPA>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 34
Summary: 

In article <2356@brl-adm.ARPA> rgenter@j.bbn.com (Rick Genter) writes:
>Not only that, but it was outright wrong.  Since the only guarantee on ++
>is that it will be evaluated before the start of the next statement, the
>compiler is free to implement the expression as:
>
>	if ( (booltemp = *cp | *cp | *cp, cp += 3, booltemp) ) {
>		...
>	}
>
True;
>or, alternatively,
>
>	if ( (cp += 3, *cp | *cp | *cp) ) {
>		...
>	}
>
False.
At least one of the *cp's will reference one of cp[0],cp[1],cp[2]
(using the original value of cp),  since the post-increment was used.
The following might be generated:

	if ( (cp += 3, cp[-1] | cp[-1] | cp[-1]) ) {

which references cp[2] three times. In fact it seems to me that any
legal ordering of *cp++|*cp++|*cp++ will generate references to
old_cp[0], old_cp[1] and old_cp[2] only, but I won't try to prove it.

Our Ns32k compiler often does "*p++" as "++p, p[-1]", and it
is conceivable that three ++cp could be folded into cp += 3 as above.

-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...