🚀 go-pugleaf

In article <18140@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>|>   printf("%d %d\n", (1, v), (1,v++));
>Hey, that looks pretty good. No matter what the order of evaluation of
>the function arguments is, there's always a sequence point separating the
>references to v. So the behavior is not undefined, yet order of evaluation
>definitely has a drastic effect on the output. 
>Anybody see a problem with that?

Yes, perhaps the order of evaluation of the subexpressions is still
unspecified even though one might think that there are sequence points
involved.  The question is whether the sequence-point constraints bind
more tightly than the unspecified-order specification or more loosely.
A similar issue arose with regard to the first formal request for
interpretation of X3.159, only in that case the sloppy-order specification
was the one permitted for assignment expressions.  In the case of that
interpretation, X3J11 finally (at the March 1991 meeting) decided that
the 3.3.16.1 license did NOT override the expectation that the function
value had to be "copied" out.  If that is taken as a precedent, then a
consistent interpretation for the above example ought to be that the
sequence point ordering is more important than the argument subexpression
evaluation ordering license.  However, without a formal interpretation
ruling I would hesitate to promise that it "must" be that way.

Certainly, nobody should write code like that!