Re: Order of argument evaluation in C++, etc.

shepherd@schubert.sbi.com (Marc Shepherd) writes:


>I wouldn't be so fast to accuse the committee of "ignoring" anything.
>It is not in their charter to wipe the slate clean and redesign the language


The C Standard committee didn't have to use the same execution model
as Algol 68, but it should have thought through the issues as carefully
as the Algol 68 standardizers did. The C Standard's ``sequence points''
formalism is poorly thought-out and expressed, leading to unnecessary
controversy about what the C Standard actually means.


For example, the C Standard, by my reading, does not define the
behavior of `F()+F()' if F's definition is `int F() {return x++;}', [1]
but it seems that most of the committee didn't want this example to have
undefined behavior -- it's just that they didn't cover the issue
carefully enough in the standard.


In my opinion, order-of-evaluation is the most important problem
area in the C Standard proper. Other language standards since Algol 68
(e.g. Ada, Fortran, PL/I, Scheme) have addressed this issue more clearly.
Future C and C++ standards should do so as well.


-----
[1] Yes, there's a sequence point before each call and after each return,
but the C Standard does not say that the second call's sequence point
must come after the first return's sequence point, or vice versa.
On the contrary, the standard explicitly gives the implementation
permission to jumble up the evaluation of sibling subexpressions,
so it is reasonable to interpret the standard as saying that the above
example has undefined behavior because the sequence points of the two
function executions can be interleaved.


When this issue came up, there was an extensive discussion of what the
standard was supposed to mean, and if memory serves, different members
of the committee took opposite positions in that discussion.
Eventually they made a decision, but the point is that the original
standard shouldn't have been so unclear.


--

Return to the comp.compilers page.
Search the comp.compilers archives again.