[Toybox] gcc warnings; order of evaluation

[Ray Gardner]

 Rob, let me know if it's inappropriate to discuss your programming-related
blog posts in the toybox list.

Your 2022-09-10 post responded to an email that said:

> ...from a sequencing point of view, I think this line is equivalent to:
> > ss = ss + sprintf(ss = toybuf, "%d", h1->pos);
> ... which has a sequencing problem because the ss read isn't sequenced
with respect to the inner ss assignment.

which was in reference to your 2022-08-24 post about gcc "warning:
operation on 'ss' may be undefined [-Wsequence-point]".

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.

But I think some of your other assertions are wrong.

> 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]
>  "x = 0; printf("%d %d\n", ++x, ++x);" varied its output back under Turbo
C

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).

> 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

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."

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20221008/964f10ec/attachment.htm>