throopw@dg_rtp.UUCP (Wayne Throop) (10/10/86)
> 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