Why are these constructs (using ++) undefined behavior in C?

#include <stdio.h>

int main(void)
{
int i = 0;
i = i++ + ++i;
printf("%dn", i); // 3

i = 1;
i = (i++);
printf("%dn", i); // 2 Should be 1, no ?

volatile int u = 0;
u = u++ + ++u;
printf("%dn", u); // 1

u = 1;
u = (u++);
printf("%dn", u); // 2 Should also be one, no ?

register int v = 0;
v = v++ + ++v;
printf("%dn", v); // 3 (Should be the same as u ?)

int w = 0;
printf("%d %d %dn", w++, ++w, w); // shouldn't this print 0 2 2

int x[2] = { 5, 8 }, y = 0;
x[y] = y ++;
printf("%d %dn", x[0], x[1]); // shouldn't this print 0 8? or 5 0?
}


13 Answers
13

C has the concept of undefined behavior, i.e. some language constructs are syntactically valid but you can't predict the behavior when the code is run.

As far as I know, the standard doesn't explicitly say why the concept of undefined behavior exists. In my mind, it's simply because the language designers wanted there to be some leeway in the semantics, instead of i.e. requiring that all implementations handle integer overflow in the exact same way, which would very likely impose serious performance costs, they just left the behavior undefined so that if you write code that causes integer overflow, anything can happen.

So, with that in mind, why are these "issues"? The language clearly says that certain things lead to undefined behavior. There is no problem, there is no "should" involved. If the undefined behavior changes when one of the involved variables is declared volatile, that doesn't prove or change anything. It is undefined; you cannot reason about the behavior.

volatile

Your most interesting-looking example, the one with

u = (u++);


is a text-book example of undefined behavior (see Wikipedia's entry on sequence points).

Just compile and disassemble your line of code, if you are so inclined to know how exactly it is you get what you are getting.

This is what I get on my machine, together with what I think is going on:

$ cat evil.c
void evil(){
int i = 0;
i+= i++ + ++i;
}
$ gcc evil.c -c -o evil.bin
$ gdb evil.bin
(gdb) disassemble evil
Dump of assembler code for function evil:
0x00000000 <+0>: push %ebp
0x00000001 <+1>: mov %esp,%ebp
0x00000003 <+3>: sub $0x10,%esp
0x00000006 <+6>: movl $0x0,-0x4(%ebp) // i = 0 i = 0
0x0000000d <+13>: addl $0x1,-0x4(%ebp) // i++ i = 1
0x00000011 <+17>: mov -0x4(%ebp),%eax // j = i i = 1 j = 1
0x00000014 <+20>: add %eax,%eax // j += j i = 1 j = 2
0x00000016 <+22>: add %eax,-0x4(%ebp) // i += j i = 3
0x00000019 <+25>: addl $0x1,-0x4(%ebp) // i++ i = 4
0x0000001d <+29>: leave
0x0000001e <+30>: ret
End of assembler dump.


(I... suppose that the 0x00000014 instruction was some kind of compiler optimization?)

gcc evil.c -c -o evil.bin

gdb evil.bin

disassemble evil

Why are these constructs undefined behavior?

gcc -S evil.c

I think the relevant parts of the C99 standard are 6.5 Expressions, §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.

and 6.5.16 Assignment operators, §4:

The order of evaluation of the operands is unspecified. If an attempt is made to modify
the result of an assignment operator or to access it after the next sequence point, the
behavior is undefined.

i=i=5

A=B=5;

C=A+B;

A=B=5;

C=A+B;

I=I=5;

The behavior can't really be explained because it invokes both unspecified behavior and undefined behavior, so we can not make any general predictions about this code, although if you read Olve Maudal's work such as Deep C and Unspecified and Undefined sometimes you can make good guesses in very specific cases with a specific compiler and environment but please don't do that anywhere near production.

So moving on to unspecified behavior, in draft c99 standard section6.5 paragraph 3 says(emphasis mine):

6.5

The grouping of operators and operands is indicated by the syntax.74) Except as specified
later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation of subexpressions and the order in which side effects take place are both unspecified.

So when we have a line like this:

i = i++ + ++i;


we do not know whether i++ or ++i will be evaluated first. This is mainly to give the compiler better options for optimization.

i++

++i

We also have undefined behavior here as well since the program is modifying variables(i, u, etc..) more than once between sequence points. From draft standard section 6.5 paragraph 2(emphasis mine):

i

u

6.5

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.

it cites the following code examples as being undefined:

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


In all these examples the code is attempting to modify an object more than once in the same sequence point, which will end with the ; in each one of these cases:

;

i = i++ + ++i;
^ ^ ^

i = (i++);
^ ^

u = u++ + ++u;
^ ^ ^

u = (u++);
^ ^

v = v++ + ++v;
^ ^ ^


Unspecified behavior is defined in the draft c99 standard in section 3.4.4 as:

3.4.4

use of an unspecified value, or other behavior where this International Standard provides
two or more possibilities and imposes no further requirements on which is chosen in any
instance

and undefined behavior is defined in section 3.4.3 as:

3.4.3

behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements

and notes that:

Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

Most of the answers here quoted from C standard emphasizing that the behavior of these constructs are undefined. To understand why the behavior of these constructs are undefined, let's understand these terms first in the light of C11 standard:

Sequenced: (5.1.2.3)

Given any two evaluations A and B, if A is sequenced before B, then the execution of A shall precede the execution of B.

A

B

A

B

A

B

Unsequenced:

If A is not sequenced before or after B, then A and B are unsequenced.

A

B

A

B

Evaluations can be one of two things:

Sequence Point:

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

B

A

B

Now coming to the question, for the expressions like

int i = 1;
i = i++;


standard says that:

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. [...]

Therefore, the above expression invokes UB because two side effects on the same object i is unsequenced relative to each other. That means it is not sequenced whether the side effect by assignment to i will be done before or after the side effect by ++.
Depending on whether assignment occurs before or after the increment, different results will be produced and that's the one of the case of undefined behavior.

i

i

++

Lets rename the i at left of assignment be il and at the right of assignment (in the expression i++) be ir, then the expression be like

i

il

i++

ir

il = ir++ // Note that suffix l and r are used for the sake of clarity.
// Both il and ir represents the same object.


An important point regarding Postfix ++ operator is that:

++

just because the ++ comes after the variable does not mean that the increment happens late. The increment can happen as early as the compiler likes as long as the compiler ensures that the original value is used.

++

It means the expression il = ir++ could be evaluated either as

il = ir++

temp = ir; // i = 1
ir = ir + 1; // i = 2 side effect by ++ before assignment
il = temp; // i = 1 result is 1


or

temp = ir; // i = 1
il = temp; // i = 1 side effect by assignment before ++
ir = ir + 1; // i = 2 result is 2


resulting in two different results 1 and 2 which depends on the sequence of side effects by assignment and ++ and hence invokes UB.

1

2

++

Another way of answering this, rather than getting bogged down in arcane details of sequence points and undefined behavior, is simply to ask, what are they supposed to mean? What was the programmer trying to do?

The first fragment asked about, i = i++ + ++i, is pretty clearly insane in my book. No one would ever write it in a real program, it's not obvious what it does, there's no conceivable algorithm someone could have been trying to code that would have resulted in this particular contrived sequence of operations. And since it's not obvious to you and me what it's supposed to do, it's fine in my book if the compiler can't figure out what it's supposed to do, either.

i = i++ + ++i

The second fragment, i = i++, is a little easier to understand. Someone is clearly trying to increment i, and assign the result back to i. But there are a couple ways of doing this in C. The most basic way to add 1 to i, and assign the result back to i, is the same in almost any programming language:

i = i++

i = i + 1


C, of course, has a handy shortcut:

i++


This means, "add 1 to i, and assign the result back to i". So if we construct a hodgepodge of the two, by writing

i = i++


what we're really saying is "add 1 to i, and assign the result back to i, and assign the result back to i". We're confused, so it doesn't bother me too much if the compiler gets confused, too.

Realistically, the only time these crazy expressions get written is when people are using them as artificial examples of how ++ is supposed to work. And of course it is important to understand how ++ works. But one practical rule for using ++ is, "If it's not obvious what an expression using ++ means, don't write it."

We used to spend countless hours on comp.lang.c discussing expressions like these and why they're undefined. Two of my longer answers, that try to really explain why, are archived on the web:

*p=(*q)++;

if (p!=q) *p=(*q)++; else *p= __ARBITRARY_VALUE;

*p

else

if

While it is unlikely that any compilers and processors would actually do so, it would be legal, under the C standard, for the compiler to implement "i++" with the sequence:

In a single operation, read `i` and lock it to prevent access until further notice
Compute (1+read_value)
In a single operation, unlock `i` and store the computed value


While I don't think any processors support the hardware to allow such a thing to be done efficiently, one can easily imagine situations where such behavior would make multi-threaded code easier (e.g. it would guarantee that if two threads try to perform the above sequence simultaneously, i would get incremented by two) and it's not totally inconceivable that some future processor might provide a feature something like that.

i

If the compiler were to write i++ as indicated above (legal under the standard) and were to intersperse the above instructions throughout the evaluation of the overall expression (also legal), and if it didn't happen to notice that one of the other instructions happened to access i, it would be possible (and legal) for the compiler to generate a sequence of instructions that would deadlock. To be sure, a compiler would almost certainly detect the problem in the case where the same variable i is used in both places, but if a routine accepts references to two pointers p and q, and uses (*p) and (*q) in the above expression (rather than using i twice) the compiler would not be required to recognize or avoid the deadlock that would occur if the same object's address were passed for both p and q.

i++

i

i

p

q

(*p)

(*q)

i

p

q

Often this question is linked as a duplicate of questions related to code like

printf("%d %dn", i, i++);


or

printf("%d %dn", ++i, i++);


or similar variants.

While this is also undefined behaviour as stated already, there are subtle differences when printf() is involved when comparing to a statement such as:

printf()

x = i++ + i++;


In the following statement:

printf("%d %dn", ++i, i++);


the order of evaluation of arguments in printf() is unspecified. That means, expressions i++ and ++i could be evaluated in any order. C11 standard has some relevant descriptions on this:

printf()

i++

++i

Annex J, unspecified behaviours

The order in which the function designator, arguments, and
subexpressions within the arguments are evaluated in a function call
(6.5.2.2).

3.4.4, unspecified behavior

Use of an unspecified value, or other behavior where this
International Standard provides two or more possibilities and imposes
no further requirements on which is chosen in any instance.

EXAMPLE An example of unspecified behavior is the order in which the
arguments to a function are evaluated.

The unspecified behaviour itself is NOT an issue. Consider this example:

printf("%d %dn", ++x, y++);


This too has unspecified behaviour because the order of evaluation of ++x and y++ is unspecified. But it's perfectly legal and valid statement. There's no undefined behaviour in this statement. Because the modifications (++x and y++) are done to distinct objects.

++x

y++

++x

y++

What renders the following statement

printf("%d %dn", ++i, i++);


as undefined behaviour is the fact that these two expressions modify the same object i without an intervening sequence point.

i

Another detail is that the comma involved in the printf() call is a separator, not the comma operator.

This is an important distinction because the comma operator does introduce a sequence point between the evaluation of their operands, which makes the following legal:

int i = 5;
int j;

j = (++i, i++); // No undefined behaviour here because the comma operator
// introduces a sequence point between '++i' and 'i++'

printf("i=%d j=%dn",i, j); // prints: i=7 j=6


The comma operator evaluates its operands left-to-right and yields only the value of the last operand. So in j = (++i, i++);, ++i increments i to 6 and i++ yields old value of i (6) which is assigned to j. Then i becomes 7 due to post-increment.

j = (++i, i++);

++i

i

6

i++

i

6

j

i

7

So if the comma in the function call were to be a comma operator then

printf("%d %dn", ++i, i++);


will not be a problem. But it invokes undefined behaviour because the comma here is a separator.

For those who are new to undefined behaviour would benefit from reading What Every C Programmer Should Know About Undefined Behavior to understand the concept and many other variants of undefined behaviour in C.

This post: Undefined, unspecified and implementation-defined behavior is also relevant.

The C standard says that a variable should only be assigned at most once between two sequence points. A semi-colon for instance is a sequence point.
So every statement of the form:

i = i++;
i = i++ + ++i;


and so on violate that rule. The standard also says that behavior is undefined and not unspecified. Some compilers do detect these and produce some result but this is not per standard.

However, two different variables can be incremented between two sequence points.

while(*src++ = *dst++);


The above is a common coding practice while copying/analysing strings.

In https://stackoverflow.com/questions/29505280/incrementing-array-index-in-c someone asked about a statement like:

int k = {0,1,2,3,4,5,6,7,8,9,10};
int i = 0;
int num;
num = k[++i+k[++i]] + k[++i];
printf("%d", num);


which prints 7... the OP expected it to print 6.

The ++i increments aren't guaranteed to all complete before the rest of the calculations. In fact, different compilers will get different results here. In the example you provided, the first 2 ++i executed, then the values of k were read, then the last ++i then k.

++i

++i

k

++i

k

num = k[i+1]+k[i+2] + k[i+3];
i += 3


Modern compilers will optimize this very well. In fact, possibly better than the code you originally wrote (assuming it had worked the way you had hoped).

While the syntax of the expressions like a = a++ or a++ + a++ is legal, the behaviour of these constructs is undefined because a shall in C standard is not obeyed. C99 6.5p2:

a = a++

a++ + a++

With footnote 73 further clarifying that

This paragraph renders undefined statement expressions such as

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


while allowing

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


The various sequence points are listed in Annex C of C11 (and C99):

The following are the sequence points described in 5.1.2.3:

The wording of the same paragraph in C11 is:

You can detect such errors in a program by for example using a recent version of GCC with -Wall and -Werror, and then GCC will outright refuse to compile your program. The following is the output of gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005:

-Wall

-Werror

% gcc plusplus.c -Wall -Werror -pedantic
plusplus.c: In function ‘main’:
plusplus.c:6:6: error: operation on ‘i’ may be undefined [-Werror=sequence-point]
i = i++ + ++i;
~~^~~~~~~~~~~
plusplus.c:6:6: error: operation on ‘i’ may be undefined [-Werror=sequence-point]
plusplus.c:10:6: error: operation on ‘i’ may be undefined [-Werror=sequence-point]
i = (i++);
~~^~~~~~~
plusplus.c:14:6: error: operation on ‘u’ may be undefined [-Werror=sequence-point]
u = u++ + ++u;
~~^~~~~~~~~~~
plusplus.c:14:6: error: operation on ‘u’ may be undefined [-Werror=sequence-point]
plusplus.c:18:6: error: operation on ‘u’ may be undefined [-Werror=sequence-point]
u = (u++);
~~^~~~~~~
plusplus.c:22:6: error: operation on ‘v’ may be undefined [-Werror=sequence-point]
v = v++ + ++v;
~~^~~~~~~~~~~
plusplus.c:22:6: error: operation on ‘v’ may be undefined [-Werror=sequence-point]
cc1: all warnings being treated as errors


The important part is to know what a sequence point is -- and what is a sequence point and what isn't. For example the comma operator is a sequence point, so

j = (i ++, ++ i);


is well-defined, and will increment i by one yield the old value, discard that value; then at comma operator, settle the side effects; and then increment i by one, and the resulting value becomes the value of the expression - i.e. this is just a contrived way to write j = (i += 2) which is yet again a "clever" way to write

i

i

j = (i += 2)

i += 2;
j = i;


However, the , in function argument lists is not a comma operator, and there is no sequence point between evaluations of distinct arguments; instead they're unsequenced with regard to each other; so the function call

,

int i = 0;
printf("%d %dn", i++, ++i, i);


has undefined behaviour because there is no sequence point between the evaluations of i++ and ++i in function arguments, and the value of i is therefore modified twice, by both i++ and ++i, between the previous and the next sequence point.

i++

++i

i

i++

++i

A good explanation about what happens in this kind of computation is provided in the document n1188 from the ISO W14 site.

I explain the ideas.

The main rule from the standard ISO 9899 that applies in this situation is 6.5p2.

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.

The sequence points in an expression like i=i++ are before i= and after i++.

i=i++

i=

i++

In the paper that I quoted above it is explained that you can figure out the program as being formed by small boxes, each box containing the instructions between 2 consecutive sequence points. The sequence points are defined in annex C of the standard, in the case of i=i++ there are 2 sequence points that delimit a full-expression. Such an expression is syntactically equivalent with an entry of expression-statement in the Backus-Naur form of the grammar (a grammar is provided in annex A of the Standard).

i=i++

expression-statement

So the order of instructions inside a box has no clear order.

i=i++


can be interpreted as

tmp = i
i=i+1
i = tmp


or as

tmp = i
i = tmp
i=i+1


because both all these forms to interpret the code i=i++ are valid and because both generate different answers, the behavior is undefined.

i=i++

So a sequence point can be seen by the beginning and the end of each box that composes the program [the boxes are atomic units in C] and inside a box the order of instructions is not defined in all cases. Changing that order one can change the result sometimes.

EDIT:

Other good source for explaining such ambiguities are the entries from c-faq site (also published as a book) , namely here and here and here .

a[i]=i++

which index of a is modified ?

i=i++

The reason is that the program is running undefined behavior. The problem lies in the evaluation order, because there is no sequence points required according to C++98 standard ( no operations is sequenced before or after another according to C++11 terminology).

However if you stick to one compiler, you will find the behavior persistent, as long as you don't add function calls or pointers, which would make the behavior more messy.

So first the GCC:
Using Nuwen MinGW 15 GCC 7.1 you will get:

#include<stdio.h>
int main(int argc, char ** argv)
{
int i = 0;
i = i++ + ++i;
printf("%dn", i); // 2

i = 1;
i = (i++);
printf("%dn", i); //1

volatile int u = 0;
u = u++ + ++u;
printf("%dn", u); // 2

u = 1;
u = (u++);
printf("%dn", u); //1

register int v = 0;
v = v++ + ++v;
printf("%dn", v); //2


}

How does GCC work? it evaluates sub expressions at a left to right order for the right hand side (RHS) , then assigns the value to the left hand side (LHS) . This is exactly how Java and C# behave and define their standards. (Yes, the equivalent software in Java and C# has defined behaviors). It evaluate each sub expression one by one in the RHS Statement in a left to right order; for each sub expression: the ++c (pre-increment) is evaluated first then the value c is used for the operation, then the post increment c++).

according to GCC C++: Operators

In GCC C++, the precedence of the operators controls the order in
which the individual operators are evaluated

the equivalent code in defined behavior C++ as GCC understands:

#include<stdio.h>
int main(int argc, char ** argv)
{
int i = 0;
//i = i++ + ++i;
int r;
r=i;
i++;
++i;
r+=i;
i=r;
printf("%dn", i); // 2

i = 1;
//i = (i++);
r=i;
i++;
i=r;
printf("%dn", i); // 1

volatile int u = 0;
//u = u++ + ++u;
r=u;
u++;
++u;
r+=u;
u=r;
printf("%dn", u); // 2

u = 1;
//u = (u++);
r=u;
u++;
u=r;
printf("%dn", u); // 1

register int v = 0;
//v = v++ + ++v;
r=v;
v++;
++v;
r+=v;
v=r;
printf("%dn", v); //2
}


Then we go to Visual Studio. Visual Studio 2015, you get:

#include<stdio.h>
int main(int argc, char ** argv)
{
int i = 0;
i = i++ + ++i;
printf("%dn", i); // 3

i = 1;
i = (i++);
printf("%dn", i); // 2

volatile int u = 0;
u = u++ + ++u;
printf("%dn", u); // 3

u = 1;
u = (u++);
printf("%dn", u); // 2

register int v = 0;
v = v++ + ++v;
printf("%dn", v); // 3
}


How does visual studio work, it takes another approach, it evaluates all pre-increments expressions in first pass, then uses variables values in the operations in second pass, assign from RHS to LHS in third pass, then at last pass it evaluates all the post-increment expressions in one pass.

So the equivalent in defined behavior C++ as Visual C++ understands:

#include<stdio.h>
int main(int argc, char ** argv)
{
int r;
int i = 0;
//i = i++ + ++i;
++i;
r = i + i;
i = r;
i++;
printf("%dn", i); // 3

i = 1;
//i = (i++);
r = i;
i = r;
i++;
printf("%dn", i); // 2

volatile int u = 0;
//u = u++ + ++u;
++u;
r = u + u;
u = r;
u++;
printf("%dn", u); // 3

u = 1;
//u = (u++);
r = u;
u = r;
u++;
printf("%dn", u); // 2

register int v = 0;
//v = v++ + ++v;
++v;
r = v + v;
v = r;
v++;
printf("%dn", v); // 3
}


as Visual Studio documentation states at Precedence and Order of Evaluation:

Where several operators appear together, they have equal precedence and are evaluated according to their associativity. The operators in the table are described in the sections beginning with Postfix Operators.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).


Would you like to answer one of these unanswered questions instead?