🚀 go-pugleaf

In article <18286@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
>In article <1991Apr5.182945.15789@cs.ucla.edu>, jon@maui.cs.ucla.edu
>(Jonathan Gingerich) writes:
>|> I would guess there
>|>is only one between the first and second expression in which case the
>|>evaluation order 1 - 1 - (sequence point) - (sequence point) - v - v++
>|>would make the result undefined.
>
>That order of evaluation would seem to be inconsistent with the Semantics
>part of 3.3.17 (Comma Operator). "The left operand of a comma operator
>is evaluated as a void expression; there is a sequence point after its
>evaluation. THEN THE RIGHT OPERAND IS EVALUATED [emphasis mine]; the
>result has its type and value."

The line read (essentially):

	f ( ( 1 , v) , ( 1 , v++ ) ) ;

I expect you're not confusing the two comma operators with the
comma separator in this function call.  The sequence point
after the left operand of each comma-operator serves only
to define the end of operations on the left operand and the
beginning of operations on the right operand; it does not
affect the order in which the two arguments to the function
are evaluated.  However, what you may be saying is that the
sequence of abstract events

        1 - 1 - ( seq. pt. ) - ( seq. pt. ) - v - v++

is incorrect, and would be

        1 - ( seq. pt. ) - 1 - ( seq. pt. ) - v - v++

or

        	                       ...  - v++ - v

implying that the sequence point must be applied to the
end of evaluation of one of the left operands before
the other can be evaluated.

It would seem so, or else

	f ( ( a=b, 1 ), ( a=c, 1 ) );

Would have undefined behavior (assigning to `a' twice
before the next sequence point), while it should have
only unspecified order of evaluation of the two arguments.

				--Blair
				  "Hey!  This stuff's *recursive*!"