Re: i = v[i++] results in undefined behavior. Can't understand why.
Armen Tsirunyan wrote:
On Sep 26, 10:00 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
Armen Tsirunyan wrote:
Please help me, I just can't understand this.
Clause 1.9 Paragraph 15 (n3092) says:
Except where noted, evaluations of operands of individual operators
and of subexpressions of individual
expressions are unsequenced. [ Note: In an expression that is
evaluated more than once during the execution
of a program, unsequenced and indeterminately sequenced evaluations of
its subexpressions need not be
performed consistently in different evaluations. ???end note ] The value
computations of the operands of an
operator are sequenced before the value computation of the result of
the operator. If a side effect on a scalar
object is unsequenced relative to either another side effect on the
same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined.
[ Example:
void f(int, int);
void g(int i, int* v) {
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // i becomes 9
i = i++ + 1; // the behavior is undefined
i = i + 1; // the value of i is incremented
f(i = -1, i = -1); // the behavior is undefined
}
???end example ]
let's consider i = v[i++]. the side effect of i being incremented by 1
is SEQUENCED before the side effect of i being assigned v[i++],
because "The value computations of the operands of an operator are
sequenced before the value computation of the result of the operator".
So how come is this undefined behavior?
Because value computations do not include side effects. So you have two
unsequenced side effects in your snippet (the increment and assignment).
Moreover you have a value computation on i (left i) that is unsequenced
relative to a side effect on i (the right "i++").
If you write this as "i = v[++i]", which is equivalent to "i = *(v + (i =
i + 1))" you will not have two unsequenced side effects anymore, because
the assignment in "i = i + 1" is sequenced before the assignment in "i =
*(...". BUT you still have the same value computation be unsequenced to
the same side effect as in your snippet. So for both the pre and postfix
version you have undefined behavior.
If I may quote you from another thread :)
++i = 0; // defined by c++0x, undefined by C++03
++ ++i; // defined by c++0x, undefined by C++03
i = ++i; // defined by c++0x, undefined by C++03
Please disregard the last one. That's still undefined in C++0x it seems.
Value computation of the left i is not sequenced relative to the side
effect of "++i".
i = ++i; whether or not this is defined depends pretty much on what a
value computation means.
In fact, we had this case of "i = ++i" on stackoverflow now. The Standard
says "If a side effect on a scalar object is unsequenced relative to either
another side effect on the same scalar object or a value computation using
the value of the same scalar object, the behavior is undefined.". The key
point is "using the value of the same scalar object". It did not appear to
me until someone actually pointed it out to me.
We found that since an lvalue that just refers to an object does not use the
value of an object, that "i = ++i" is not UB. While "i" on the left side is
a value computation of that lvalue expression "i", it does not use the value
of the scalar object i. So we have "value computation" that acts on
expressions, but does not use the value of the object that it computed an
lvalue to, in case of glvalue evaluation. I suspect that this is a
reasonable reading of the Standard.