<div><div dir="ltr"> Rob, let me know if it's inappropriate to discuss your programming-related blog posts in the toybox list.<div><br></div><div>Your 2022-09-10 post responded to an email that said:</div><div><br></div><div>> ...from a sequencing point of view, I think this line is equivalent to:<br>> > ss = ss + sprintf(ss = toybuf, "%d", h1->pos);<br>> ... which has a sequencing problem because the ss read isn't sequenced with respect to the inner ss assignment.<br><br>which was in reference to your 2022-08-24 post about gcc "warning: operation on 'ss' may be undefined [-Wsequence-point]".<br><br>I think your respondent is not quite right, because C says += only evaluates the left side once. I asked the folks at StackOverflow about this, and I think the consensus (and my own understanding) is that the warning is bogus, as you said; updating ss this way is not undefined behavior. There is a sequence point before the sprintf() call and again at the end of the statement, so ss is not updated more than once between sequence points. Though there is some question about whether the wording in the standard exactly covers this case.</div><div><br></div><div>But I think some of your other assertions are wrong. <br><br>> the order of argument evaluation was reversed for people doing "pascal" stack order ... the standards commitee cowardly refused to specify behavior in a way that would outlaw stupid things microsoft was doing. [from 8-24]<br>>  "x = 0; printf("%d %d\n", ++x, ++x);" varied its output back under Turbo C<br><br>The order of evaluation of function args had nothing to do with Turbo C (or Microsoft), it was explicitly undefined in K&R 1 (1978).<br><br>> If I know "int x = 0; x = printf("%d\n", x++) + printf("%d\n", x++); printf("%d\n", x);" is GOING to perform those first two printf() calls in order<br><br>That's also undefined in C, as far back as 1974 (Ritchie). "Otherwise 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 subexpressons involve side effects." K&R 1 went so far as "Expressions involving a commutative and associative operator (*, +, &, |, ^) may be rearranged arbitrarily, even in the presence of parentheses; to force a particular order of evaluation an explicit temporary must be used."<br><br>I think there's plenty of room to argue about overly aggressive optimizers, especially involving aliasing issues. I've read somewhere (can't find it now) that some standard committee members aren't happy with the way the anti-aliasing rules (C standard 6.5 par. 7) are stated. But the order of evaluation issues were pretty well settled in C89 with the "sequence point" concept that mostly just clarified what Ritchie had stated for 15 years already.<br><br></div></div>
</div>