[cpp-threads] Troublesome sequencing example

[Nelson, Clark]

I have decided that I am not satisfied with an aspect of the situation
described in N2052, specifically concerning the example in 1.9p17 (which
was originally supplied by Peter Dimov, if I recall correctly). Here is
that example in its current form:

int inc_x() { return x++; }

x++ + inc_x();	// Evaluation order unspecified
			// Effect of inc_x may be lost:
			// Call may occur between load and store of x

I firmly believe that in the status quo according to the published C and
C++ standards, there are aspects of this example that are unspecified,
but that there's definitely no undefined behavior. (This is also true
with the proposed changes.) What I have never liked, and have finally
decided to oppose, is the implication that the side effect of an
increment might be lost in a case that does not fall into the category
of undefined behavior.

This implication arises from the absence of a clear prohibition against
executing the body of the called function between various sub-operations
of the increment operation: specifically, between the evaluation of the
lvalue-to-rvalue conversion that fetches the previous value of x and the
side effect that stores its new value.

My preferred outcome would be to add that clear prohibition for
post-increment, and similarly for compound assignment (and therefore for
pre-increment), and to delete the example. Editorially speaking, my
inclination would be to add the prohibition to the descriptions of the
relevant operators, along these lines (and of course analogously with
compound assignment):

With respect to an indeterminately-sequenced function call, a postfix
increment or decrement is a single evaluation. [Note: Therefore, a
function call shall not intervene between the lvalue-to-rvalue
conversion and the side effect associated with any single postfix
increment or decrement operation. -- end note]

I think this works together with the key sentence from 1.9p17:

Every evaluation in the calling function (including other function
calls) that is not otherwise specifically sequenced before or after the
execution of the body of the called function is indeterminately
sequenced with respect to the execution of the called function.

(It might be reasonable instead to add this prohibition for both
post-increment and compound assignment directly to 1.9p17, but that's an
editorial question.)

If this outcome were to be considered an unacceptable change from the
status quo according to the published standards, then my (distant)
second choice would be to change the rules such that the above example
would be categorized as having undefined behavior. The status quo
according to N2052 would be my third choice.

Any objections from this group? Hans?

-- 
Clark Nelson		Vice chair, J16 (ANSI C++ standard committee)
Intel Corporation
clark.nelson at intel.com