C programming: is this undefined behavior?

Question

Our class was asked this question by the C programming prof:

You are given the code:

int x=1;
printf("%d",++x,x+1);

What output will it always produce ?

Most students said undefined behavior. Can anyone help me understand why it is so?

Thanks for the edit and the answers but I'm still confused.

Answer 1

Output will be 2 always.

Here printf is receiving 2 parameters but printing only the first one. Now the order of function argument evaluation is undefined in C so the printf might receive (2,3) or (2,2). In either case only 2 will be printed.

If the printf is changed to printf("%d %d", ++x, x+1) then the result will be undefined.

Answer 2

Most students said undefined behavior. Can anyone help me understand why it is so?

Because order in which function parameters are calculated is not specified.

Answer 3

What output will it always produce ?

It will produce 2 in all environments I can think of. Strict interpretation of the C99 standard however renders the behaviour undefined because the accesses to x do not meet the requirements that exist between sequence points.

Most students said undefined behavior. Can anyone help me understand why it is so?

I will now address the second question which I understand as "Why do most of the students of my class say that the shown code constitutes undefined behaviour?" and I think no other poster has answered so far. One part of the students will have remembered examples of undefined value of expressions like

f(++i,i)

The code you give fits this pattern but the students erroneously think that the behaviour is defined anyway because printf ignores the last parameter. This nuance confuses many students. Another part of the student will be as well versed in standard as David Thornley and say "undefined behaviour" for the correct reasons explained above.

Answer 4

Any time the behavior of a program is undefined, anything can happen — the classical phrase is that "demons may fly out of your nose" — although most implementations don't go that far.

The arguments of a function are conceptually evaluated in parallel (the technical term is that there is no sequence point between their evaluation). That means the expressions ++x and x+1 may be evaluated in this order, in the opposite order, or in some interleaved way. When you modify a variable and try to access its value in parallel, the behavior is undefined.

With many implementations, the arguments are evaluated in sequence (though not always from left to right). So you're unlikely to see anything but 2 in the real world.

However, a compiler could generate code like this:

1. Load x into register r1.
2. Calculate x+1 by adding 1 to r1.
3. Calculate ++x by adding 1 to r1. That's ok because x has been loaded into r1. Given how the compiler was designed, step 2 cannot have modified r1, because that could only happen if x was read as well as written between two sequence points. Which is forbidden by the C standard.
4. Store r1 into x.

And on this (hypothetical, but correct) compiler, the program would print 3.

(EDIT: passing an extra argument to printf is correct (§7.19.6.1-2 in N1256; thanks to Prasoon Saurav) for pointing this out. Also: added an example.)

Answer 5

The output is likely to be 2 in every reasonable case. In reality, what you have is undefined behavior though.

Specifically, the standard says:

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 sequence point before evaluating the arguments to a function, and a sequence point after all the arguments have been evaluated (but the function not yet called). Between those two (i.e., while the arguments are being evaluated) there is not a sequence point (unless an argument is an expression includes one internally, such as using the && || or , operator).

That means the call to printf is reading the prior value both to determine the value being stored (i.e., the ++x) and to determine the value of the second argument (i.e., the x+1). This clearly violates the requirement quoted above, resulting in undefined behavior.

The fact that you've provided an extra argument for which no conversion specifier is given does not result in undefined behavior. If you supply fewer arguments that conversion specifiers, or if the (promoted) type of the argument disagrees with that of the conversion specifier you get undefined behavior -- but passing an extra parameter does not.

Answer 6

The correct answer is: the code produces undefined behavior.

The reason the behavior is undefined is that the two expressions ++x and x + 1 are modifying x and reading x for an unrelated (to modification) reason and these two actions are not separated by a sequence point. This results in undefined behavior in C (and C++). The requirement is given in 6.5/2 of C language standard.

Note, that the undefined behavior in this case has absolutely nothing to do with the fact that printf function is given only one format specifier and two actual arguments. To give more arguments to printf than there are format specifiers in the format string is perfectly legal in C. Again, the problem is rooted in the violation of expression evaluation requirements of C language.

Also note, that some participants of this discussion fail to grasp the concept of undefined behavior, and insist on mixing it with the concept of unspecified behavior. To better illustrate the difference let's consider the following simple example

int inc_x(int *x) { return ++*x; }
int x_plus_1(int x) { return x + 1; }

int x = 1;
printf("%d", inc_x(&x), x_plus_1(x));

The above code is "equivalent" to the original one, except that the operations that involve our x are wrapped into functions. What is going to happen in this latest example?

There's no undefined behavior in this code. But since the order of evaluation of printf arguments is unspecified, this code produces unspecified behavior, i.e. it is possible that printf will be called as printf("%d", 2, 2) or as printf("%d", 2, 3). In both cases the output will indeed be 2. However, the important difference of this variant is that all accesses to x are wrapped into sequence points present at the beginning and at the end of each function, so this variant does not produce undefined behavior.

This is exactly the reasoning some other posters are trying to force onto the original example. But it cannot be done. The original example produces undefined behavior, which is a completely different beast. They are apparently trying to insist that in practice undefined behavior is always equivalent to unspecified behavior. This is a totally bogus claim that only indicate the lack of expertise in those who make it. The original code produces undefined behavior, period.

To continue with the example, let's modify the previous code sample to

printf("%d %d", inc_x(&x), x_plus_1(x));

the output of the code will become generally unpredictable. It can print 2 2 or it can print 2 3. However note that even though the behavior is unpredictable, it still does not produce the undefined behavior. The behavior is unspecified, bit not undefined. Unspecified behavior is restricted to two possibilities: either 2 2 or 2 3. Undefined behavior is not restricted to anything. It can format you hard drive instead of printing something. Feel the difference.

Answer 7

The points made about undefined behavior are correct, but there is one additional wrinkle: printf may fail. It's doing file IO; there are any number of reasons it could fail, and it's impossible to eliminate them without knowing the complete program and the context in which it will be executed.

Answer 8

The correct answer is that, from a formal point of view, the code is labelled as "undefined behaviour". This has nothing to do with logic or Superior Laws. Simply, the standard tries to define what can be done and what can't be, or what produces "good" code and what produces "bad" code, what it is guaranteed to work and what is not, and between standard and what actually happens there are people that have to interpret the standard, in order to write a compiler or in order to write reliable code or to judge someone else code.

So, from this point of view, there's nothing to be understood: the standard defines the code as "undefined behaviour" (of course, indirectly: your code it not present as example in the standard's papers!). You learn the standard, apply it blindly to analyse your code, and say if it is "good" or not. Formally and blindly often are two dangerous words, so let's take a look at your code of our own. Since after all, for languages that has one, it is the standard that defines the language, and not viceversa (even though common practice or implementation can trigger a modification of the standard), let's start from a code that is considered good.

int x=1;
printf("%d %d",x+1,x+1);

Compiler does not need to know anything about printf, even though extensions allow to say if a function is a "printf-like" function, to add extra checking... but these are compiler tricks to help programmers, not mandatory features. Moreover, printf is described in the standard (not the language part) too, and this is why I added the %d: the code of printf, using the stdargs variable argument feature (another stuff described by the standard), scans the first argument to use properly the others.

So, if the descriptor (%d) and the argument (x+1) does not match, we are doing something wrong. I don't know if the standard labels this "undefined behaviour". However we can be sure strange things may happen. (Compiler may check for it, but the feature is not mandatory, more likely it is an "extension" provided by many if not all compilers).

Now let's take a look at printf. In order to pick its arguments, it will use va_start, va_arg and va_end. Let's take into account only va_arg, which is a macro by the way. It is the way you can pick the next argument and cast it to the datum you expect. The cast is driven by the "%d", "%s" and so on, and the cast determines also the size of the argument, so that the macro can access the next.

Knowing this, you can easily imagine that if things do not match, odd things may happen.

Now, what if we call va_arg once more (with respect to the actual number of argument passed)? Of course, we go and pick a datum on the stack (or wherever) that do not "match" anything real or usable.

What does it happen if we pick one less? Nothing special! It is perfectly doable and "legal". Of course, it could be a clue about the fact that you're doing something wrong, but it could be also intentional (in general, in the printf particular case, it would be only odd)... Nonetheless, you can do it; again, compilers may treat printf and similar in a special way and check if each "%" has its matching argument(s) and warn if more (a dangerous case) or less (the no-harm case) arguments are passed.

So

int x=1;
printf("%d",x+1, x+1);

is still good.

Now let's talk briefly about side-effects. Considered as "atomic" expression, both x+1 have no side-effects. The x is unchanged. Someone in comments said that implementation could indeed modify x in memory. This is ok, if and only if the modification is reverted and all "atomically", i.e. the modification can't be seen outside the expression. If it could happen, even the perfectly legal code I've written so far could fail.

Now, let's modify the code to change it into the bad "undefined behaviour".

int x=1;
printf("%d",++x, x+1);

Why is this code "undefined behaviour"? It is so since standard says so. No special reason, but indeed the fact must be a consequence of something; currently the only reason I can see is the order of evaluation; no matter what other people says here, at least currently, since explanations are citing the standard "rule" and not the reason behind the rule (the parallel argument fits "Unspecified Behaviour" well so that the existance of that Undefined Behaviour is still unjustified - this is also why in this answer it will seem I am confusing Undefined with Unspeficied still)

Moreover in a lazy attempt to pick a fast definition for "sequence point", I landed on wikipedia, where the note 3 cite the same piece of the standard cited in another answer here, but with the observation that "Accessing the value of j inside f therefore invokes undefined behavior", and I interpret this so that printf("%d", inc_x(&x), x_plus_1(x)) is Undefined Behaviour too, and not only Unspecified behaviour, as said in that answer.

If the standard would dictate that expressions must be evaluated in order, "from left to right" in out example, we could be able to predict the passed arguments. In fact, first will be evaluated ++x, and the second arg pushed would be 2, and x would be now 2; then x+1 would be evaluated as 2+1, i.e. 3, and the third argument would be 3.

Given an order of evaluation, we can predict the real values of the arguments.

It is worth noting that many languages do not allow assignments into expression (++x could be read as x = x + 1). If we would be forced to write x++; printf("%d %d", x, x+1) there wouldn't be problems...

Anyway... If the order of evaluation is not forced upon implementation, each implementation can pick up one; even the same implementation, according to optimizations or for whatever reasons, could use different order of evaluation in the same code.

So we have two possibilities, as already written by another user: (2, 2) (first x+1, then ++x), or (2, 3) (first ++x, then x+1). Other options are not possible since they would break even "legal" code.

But your printf ignores (and vararg functions can do it legally) the third value, so it happens that the output is predictable and it is always 2.

Are there any reason why one could say that indeed "special" implementation could output a value different from 2? Theoretically could an evil programmer write a compiler that purposely gives "random outputs" when an UB, as defined by the standard, is met?

The short answer is no, since doing so the compiler could break its ability to compile correctly some "legal" code (it suffices the existance of one of such a code); demonstrating it formally would be long - and I am not sure I am able to. But it is not important.

What I think it shouldn't be forgotten, is the fact that behind UBs or whatever, there are reasons that should sound "logical" within the "system". Saying a priori that a complex expression like printf("%d", ++x, x+1) must be UB, is illogical. It must instead be a consequence of a "relaxed condition", or of a basic "axiom" we can "backtrack".

The complex description provided in the standard by someone

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

does not explain too much of those reasons, maybe even though we also give the standard definition for "sequence point", "stored value", "evaluation", "expression", to be pedantic.

If I consider printf("%d", ++x, x+1) as an expression and sequence points ++x and x+1 among others, stored value of the object x is modified only once. The whole "expression", modifies the stored value of x only once. So, in this "interpretation" of ungiven definitions, what makes the code bad should be the second part, from "furthermore".... .... ... ...

To teachers students could answer simply: "according to current standard, it is formally undefined behaviour; but implementations not purposely built to work with this particular UB, should output 2 because " (and here you can add the explanation I've given before).

Answer 9

Echoing codaddict the answer is 2.

printf will be called with argument 2 and it will print it.

If this code is put in a context like:

void do_something()
{
    int x=1;
    printf("%d",++x,x+1);
}

Then the behaviour of that function is completely and unambiguously defined. I'm not of course arguing that this is good or correct or that the value of x is determinable afterwards.