throopw@dg_rtp.UUCP (Wayne Throop) (10/02/86)
Some folks have said that since (,) expressions are sequence points,
the result of the expression in the Subject: line must be 6.
I don't think so. I could be wrong, but it seems pretty straightforward
to me. Take this example:
(e1,e2)+(e3,e4)
Now, the way I read ANSI, the sequence points at the (,) expressions
prohibit the interleaving of the evaluation of e1 and e2, and similarly
prohibits the interleaving of e3 and e4. But it does *NOT* (as far as
I can tell) prohibit the interleaving of e1 and e3, e1 and e4, e2 and e3,
or e2 and e4. Thus, in the example that started the whole thing (the
expression in the Subject: line) the result could legitimately be anything
from 3 to 9, inclusive.
It is true that Harbison and Steele proposed a more restrictive set of
interleaving prohibitions. These were *NOT* adopted by ANSI. And,
perhaps more importantly, they were never implemented by most compilers.
Therefore, it is unwise to expect the H&S recommended behavior, since
most compilers do not adhere to it, and it is *INCORRECT* to say that
compilers that do not adhere to it are "buggy" or "broken", since both
K&R and the ANSI standard disagree with H&S on this point.
--
At one point I thought it would be easier to rewrite all my books
without using the letter 's'.
--- D.E. Knuth
--
Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopwthroopw@dg_rtp.UUCP (Wayne Throop) (10/02/86)
Awright, awright, I forgot to parenthesize the assignments to b.
I will also take this opportunity to point out that ANSI *might* be
taken to imply a must get 6, if the meaning of their wording
restricting interleaving of expressions isn't what I think it is.
--
At one point I thought it would be easier to rewrite all my books
without using the letter 's'.
--- D.E. Knuth
--
Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopwfouts@AMES-NAS.ARPA (10/03/86)
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
subexpressions.
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 3.3.16.1 (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@ames-nas.
Marty