7

C99 Standard:

Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression

C11 Standard:

If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.

So was this definition by the C99 standard incomplete and hence it was updated in C11 since it only contains the term object and not scalar object?

chqrlie
  • 131,814
  • 10
  • 121
  • 189
  • Could be related to the much improved memory model of C11, in the context of multi-threading – Basile Starynkevitch May 07 '20 at 09:08
  • Afaik, the C11 standard generally avoids the use of the term "sequence point". I believe it was deemed not to interact well both with optimizers (too restrictive) and usability (I believe multi-threading was a major concern). The change in the wording basically replaces this term with the new notion of relative sequencing. – cmaster - reinstate monica May 07 '20 at 09:15
  • @cmaster-reinstatemonica Nah that's some myth which I believe was created by C++11 (C++14?) programmers. Sequence points are all over C11, in normative text, as well as informative Annex C which summarizes them all. Sometimes C11 says "sequenced before/after", sometimes it says "there is a sequence point". – Lundin May 07 '20 at 09:19
  • Maybe you could add your example from the [other question](https://stackoverflow.com/q/61651790/12139179) before to illustrate your full concern to the others as we discussed in the [comments](https://stackoverflow.com/questions/61651790/is-b-a-scalar-object-in-this-case/61651913?noredirect=1#comment109054003_61651913) to my answer. – RobertS supports Monica Cellio May 07 '20 at 09:22
  • @RobertS supports Monica Cellio https://stackoverflow.com/a/61650429/13469230 –  May 07 '20 at 09:25
  • @RobertSsupportsMonicaCellio Hmm well come to think of it I wonder why they added "scalar". Most operators do work on scalars only, but not all of them (`.` for structs etc). – Lundin May 07 '20 at 09:36
  • @JensGustedt But how can you even have multiple side effects on an aggregate type in the same expression? If I type `array[i]=0`, it actually gives a scalar pointer operand to the [] operator. So is the side effect of modifying an object here done on an aggregate array type or the scalar item `array[i]`, or both at once? If the standard simply said "object", then it wouldn't be ambivalent. – Lundin May 07 '20 at 10:04

1 Answers1

6

This is because C11 attempted to cover multi-threading/parallel execution. The fundamental rules of program execution in the "abstract machine" added this cumbersome text between C99 and C11 (C11 5.1.2.3/3):

Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations executed by a single thread, which induces a partial order among those evaluations. Given any two evaluations A and B, if A is sequenced before B, then the execution of A shall precede the execution of B. (Conversely, if A is sequenced before B, then B is sequenced after A.) If A is not sequenced before or after B, then A and B are unsequenced. Evaluations A and B are indeterminately sequenced when A is sequenced either before or after B, but it is unspecified which.13) The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B. (A summary of the sequence points is given in annex C.)

Therefore the part you quote (C99 6.5/2) was changed accordingly, to suit the definition of program execution in the abstract machine, which supposedly now also covers parallel execution. Unfortunately - since the C99 text was so much more readable. Technically, nothing changed at all, if you don't consider parallel execution. The rules about sequence points from C99 still apply, it's just a different wording. This change also meant to synchronize C11 with C++11 which has similar rules.

Lundin
  • 195,001
  • 40
  • 254
  • 396