Thread: undefined behaviour

Originally Posted by Saurabh Mehta

But it is evident that the final value in 'i'(if i=1) would be 3..Can someone please clear my doubt..

The standard says that such expressions result in undefined behaviour, so they result in undefined behaviour and must be avoided, even if you think that the behaviour will give the same result no matter what. The point is that the compiler is not required to follow your reasoning: there might be some kind of optimisation for which the result would be say, 2.

Originally Posted by Saurabh Mehta

.But it is evident that the final value in 'i'(if i=1) would be 3..Can someone please clear my doubt..

It may be evident to you, but the standard (by allowing the behaviour to be undefined) does not mandate anything about how a compiler will interpret that code.

Let's look at the case

Code:

    i = ++j + 1;

(where j is not an alias for i), and j initially has a value of 1.

One interpretation of this is that
1) Value of 1 is stored in register A.
2) Value of j is fetched into register B.
3) Register B is incremented.
4) Value in Register B is added to value in Register A.
5) Value in register A is copied to variable i.
6) Value in Register B is copied to variable j.

This is not the only way it might be done, but this sequence of events is guaranteed to give the required results. The end result is that j has been incremented, and i has a value equal to the original j plus 2.

Now, let's say the compiler does the same thing, except that j is an alias for i. (All I've done in the sequence below is take the sequence above, and substitute i where it referred to j).
1) Value of 1 is stored in register A.
2) Value of i is fetched into register B.
3) Register B is incremented.
4) Value in Register B is added to value in Register A.
5) Value in register A is copied to variable i.
6) Value in Register B is copied to variable i.

(Notice that Step 6 cancels out the effect of Step 5). The end result, if i initially has the value of 1, is that i will have the value of 2.

Now you could argue that the compiler should detect that i and j are aliased, and emit different code. That is not always possible. For example, if in one source file

Code:

void stuff(int *x, int *y)
{
     *x = ++(*y) + 1;
}

and in another

Code:

#include <stdio.h>
void stuff(int *, int *);

int main()
{
     int i = 1;
     stuff(&i, &i);
     printf("%d\n", i);
}

the compiler has no way of knowing that x and y point to the same int. Yes, you can detect it. But a compiler is not required to do such error checking for you.

Originally Posted by nonoob

i=++i +1 does not constitute a multiple sequence point issue. The expression on the right of the assignment is evaluated without any conflicts. The variable is not referenced and updated more than once. Then the assignment is made (lowest precedence in this case) - which happens to involve a variable that's long since been accessed and forgotten. The post-increment implicit assignment is simply overridden.

The full rule, according to C99, is:

Originally Posted by C99 Clause 6.5 Paragraph 2

Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.

There is a corresponding note:

Originally Posted by C99 Clause 6.5 Note 70

This paragraph renders undefined statement expressions such as

Code:

i = ++i + 1;
a[i++] = i;

while allowing

Code:

i = i + 1;
a[i] = i;

Hence, contrary to your claim, i=++i+1 does constitute an issue with modifying a value more than once between consecutive sequence points. What you may have missed is that the assignment operator does not introduce a sequence point.

Originally Posted by nonoob

I thought surely an assignment is a sequence point.

You thought wrong.

Originally Posted by nonoob

Especially since it has a low precedence it should be executed last.

It does. But that has nothing to do with how many times particular variables have their values fetched, or have their values modified. That is why the standard specifies a limit on such things (i.e. once per expression), as per the text that laserlight quoted.

In the expression "i = ++i + 1", two of the operators (pre-increment and assignment) each work by modifying their operand (which is i in both cases). That means the expression requires two modifications of i, which runs afoul of the upper limit that i can only be modified once. Hence the expression yields undefined behaviour.

Originally Posted by nonoob

Especially since it has a low precedence it should be executed last.

Originally Posted by grumpy

It does.

[/quote]
I would hasten to add that "it does" in this case because there is no alternative order of evaluation in which the assignment, due to the low precedence, cannot be evaluated last. In general, precedence is concerned with grouping, not order of evaluation.