a = ((b=1,b)) + ((b=2,b)) + ((b=3,b))

fouts at AMES-NAS.ARPA fouts at AMES-NAS.ARPA
Sat Oct 4 04:38:05 AEST 1986

     I haven't been following the debate over this issue, but my office mate
drew me in to it this morning.  After several hours, we are convinced that
the issue hinges on the order of evaluation of subexpressions within

To explain this, let me introduce another example:

a = ( (b-c) - (d-e) ) - ( (f-g) - (h-i) )

in which I deliberately chose the minus operator, since C can't remove the
parenthesis; and I deliberately avoid side effects.

If we label the four subepressions:

        1       2           3       4
a = ( (b-c) - (d-e) ) - ( (f-g) - (h-i) )

and the two larger subexpressions:

a = ( (b-c) - (d-e) ) - ( (f-g) - (h-i) )
            A                   B

     Then, we know that 1 and 2 have to be evaluted before A and that 3 or 4
have to be evaluated before B.  But, there is no apparent constraint on the
evaluation of 1 and 2 with respect to 3 and 4 or of 1 with respect to 2 or 3
with respect to 4.  Any of a large number of evaluations including 1234AB,
12A34B, and 132A4B are possible, and as far as we can tell legal.

Turning back to the example, let us label it as

         A           B           C
a = ((b=1),b) + ((b=2),b) + ((b=3),b)
       1   2       3   4       5   6

In this case, the comma operator requires that 1 be before 2 be before A,
that 3 be before 4 be before B, and that 5 be before 6 be before C.
However, it doesn't require that 1 be before 3 or 3 be before 5, so, beside
the intended operation order (12A)(34B)(56C) and any of the permutations, it
also appears legal to do 123456ABC which would yield 9, and all other
possible permutations leading to any value between 3 and 9 being possible.

The ambiguity in the draft standard appears in the definition of the comma
operator.  The May 86 draft says in section (pg 46, line 682):

"The comma operator is a sequence point.  The left operand of a comma
operator is evaluated as a void expression.  Then the right operand is
evaluated; . . ."

     The ambiguity comes in the 'then' part, which doesn not appear to
prevent intervening calculation of other subexpressions.

I would be interested in any comments, but I don't read this list, so please
reply directly to me at fouts at ames-nas.


More information about the Comp.lang.c mailing list