🚀 go-pugleaf

> gunnar@hafro.UUCP (Gunnar Stefansson)
>> C90630JG%WUVMD.BITNET@wiscvm.ARPA
>>> tomc@oakhill.UUCP (Tom Cunningham)

>>>    a = ((b=1),b) + ((b=2),b) + ((b=3),b)
>>>I expected the result to be 6.
>>Tom, I agree, the result should be 6, as defined by K&R,
> Surely anything else isn't just strange, bizarre,..., but
> just plain a compiler bug.

Wrong, wrong, wrong, wrong, wrong.  Looking in the index of K&R under
"order of evaluation", we find some interesting quotes.  In particular,
page 185.

    [Other than prescedence noted in the previous paragraph]
    the order of evaluation of expressions is undefined.  In particular,
    the compiler considers itself free to compute subexpressions in the
    order it believes most efficient, even if the subexpressions involve
    side effects.

If this is a guarantee of some reasonable order of evaluation, then I'm
a mongoose.  This is direct, simple liscense for a K&R conforming
compiler to evaluate all the left sides of (,) expressions first, then
the right sides, then the additions, yielding 9.  How anybody who has
looked for K&R's guarantees of order of evaluation (which are minimal)
could possibly think that K&R guarantees the answer 6 is beyond me.  Did
any of you three look it up?

Again folks, play it safe: *NEVER* have two side-effects on a single
object in a single expression.

--
"Mowe bweifing?"
"More breifing!"
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw