Sequence points and side effects: Quiet change in C11?

C11 (and also C++11) has completely reworked the wording of sequencing because C11 now has threads, and it had to explain what sequencing between threads that access the same data means. The intention of the committee was to keep things backward compatible to C99 for the case where there is only one thread of execution.

Let's have a look at the C99 version:

1. Between the previous and next sequence point

2. an object

3. shall have

4. its stored value modified at most once

5. by the evaluation of an expression.

compared to the new text

If a side effect on

different terminolgie for 4, modifying the stored value

a scalar object

a restriction of the previous wording in 2. The new text only sayssomething about scalar objects

is unsequenced relative to either

unsequenced is a generalization of the concept in 1. that two statementswere separated by a sequence point. Think of two threads that modifythe same data without using a lock or something similar.

a different side effect on the same scalar object

the object is only allowed be modified once

or a value computation using the value of the same scalar object,

or a read of the value may not appear concurrently to the modification

the behavior is undefined.

The "shall" in 3. is saying this implicitly. All "shall"s lead to UB ifthey are not fulfilled.

I'm a little confused… I read C11 (2) as "[…] either (a different side effect on the same scalar object) or (a value computation using the value of the same scalar object) […]" which seems to not even allow foo = ++i (there is a side effect and we use a value depending on the changed object).

If you read the standard quote carefully

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.⁸⁴⁾

then you will find that your wording should be:

If a side effect on a scalar object is unsequenced relative to either (a different side effect on the same scalar object) or (a value computation using the value of the same scalar object).

This means that foo = ++i is a defined statement. It is true that there is a side effect on i (on foo also) but nothing is unsequenced here for the object i.

This is an explanation of foo = ++i but not really an answer to the question.

Prefix increment is defined in terms of compound assignment, see 6.5.3/2

The expression ++E is equivalent to (E+=1)

For assignment in general, there's a guarantee in 6.5.16/3

The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands. The evaluations of the operands are unsequenced.

So foo = ++i is equivalent to foo = (i+=1). The inner i+=1 requires the modification of i to be sequenced after the computation i+1. The resulting value of the expression (i+=1) is specified in 6.5.16/3 as:

An assignment expression has the value of the left operand after the assignment, but is not an lvalue.

It seems as if this requires the value computation of i+=1 to be sequenced after the modification of i, and in C++11, this is even guaranteed explicitly [expr.ass]/1

In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression.

(which is clearer to me, but I know C++ far better than C)

The modification of i is sequenced before the value computation of i+=1, so we don't have UB accessing the value of ++i in foo = ++i (as the value computation of the left and right operands of foo = x are sequenced before the modification of foo).