Is the output of printf (“%d %d”, c++, c); also undefined?

Question

I recently came across a post What is the correct answer for cout << c++ << c;? and was wondering whether the output of

int c = 0;  
printf (         


        

Answer 1

The behavior of the program is undefined because it has violated the requirements of 6.5 Expressions:

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.

c++ and c are both evaluated without an intervening sequence point, and the prior value of c is read both to determine the value to be stored by c++, and to determine the value of the expression c.

Answer 2

I have studied in lectures that post-fix and prefix operators increment value only after getting a semicolon.

Send your lecturer to me so that I can take a baseball bat to him politely point out his mistake.

Exactly when the side effect of either pre- or postfix ++ and -- is applied is unspecified, apart from the requirement that it happen before the next sequence point. In an expression like

x = a++ * b

a may be updated immediately after a++ has been evaluated, or the update may be deferred until a++ * b has been evaluated and the result assigned to x, or anywhere in between.

This is why expressions like i++ * i++ and printf("%d %d", c++, c) and a[i++] = i and a host of others are all bad juju. You will get different results based on the compiler, optimization settings, surrounding code, etc. The language standard explicitly leaves the behavior undefined so that the compiler is under no obligation to "do the right thing", whatever the right thing may be. Remember, the definition for undefined behavior is

3.4.3

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

2 NOTE 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).

3 EXAMPLE An example of undefined behavior is the behavior on integer overflow.

This is a deliberate design decision - the rationale for leaving the order of these operations unspecified is to give the implementation freedom to rearrange the evaluation order for optimization purposes. However, in exchange for this freedom, certain operations will not have well-defined results.

Note that a compiler is free to try to detect these cases and issue a diagnostic; printf("%d %d", c++, c); would be easy enough to catch, but this would be a bugger to detect in the general case. Imagine if that had been written printf("%d %d", (*p)++, c); if p points to c, then the behavior is undefined, otherwise it's okay. If p is assigned in a different translation unit, then there's no way to know at compile time whether this is a problem or not.

This concept is not difficult to understand, yet it is one of the most consistently misunderstood (and mis-taught) aspects of the C language. No doubt this is why the Java and C# language specifications force a specific evaluation order for everything (all operands are evaluated left-to-right, and all side effects are applied immediately).

Answer 3

I have studied in lectures that post-fix and prefix operators increment value only after getting a semicolon

This is not how the standard describes it. A sequence point is a point in code in which side effects which may have occurred in previous parts of the code have been evaluated. The comma between arguments to a function is not a sequence point, so the behavior there is undefined.

The evaluation order of function arguments is unspecified. There is no guarantee that the arguments to a function will be evaluated in the order (1, 2, N), so there is no guarantee that the increment will be evaluated before the second argument is passed.

So according to me, the output 0 0 is correct !!!

No, the behavior is undefined, so you cannot reasonably claim that the output will be 0 0.

Answer 4

This program exhibits a combination of both unspecified behavior and undefined behavior. Starting with the unspecified behavior, the draft C99 standard in section6.5 paragraph 3 says:

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.

It also says except as specified later and specifically cites function-call (), so we see that later on the draft standard in section 6.5.2.2 Function calls paragraph 10 says:

The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call.

So we do not know whether the read of C or the evaluation of C++ will happen first at this line of code:

printf ("%d %d", c++, c); 

furthermore, in section 6.5.2.4 Postfix increment and decrement operators paragraph 2 says:

[...] After the result is obtained, the value of the operand is incremented. [...] The side effect of updating the stored value of the operand shall occur between the previous and the next sequence point.

So all we know is that when performing the post increment c will be updated after its value is read but before the next sequence point which is right before printf is called but nothing else. As for the undefined behavior, if we look at section 6.5 paragraph 2 from the draft standard, is 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.

In the printf expression cs prior value is being read in order to evaluate both C++ and C and so we now are in undefined territory.

Answer 5

The behaviour will be definitely undefined due to the undefined evaluation order of parameters. You can prove this "undefined output" doing some random testing:

printf("%d %d\n", c++, c);
// result: 0 1
printf("%d %d %d\n", c++, c, c++);
// result: 1 2 0
printf("%d %d %d %d\n", c++, c++, c++, c);
// result: 2 1 0 3
printf("%d %d %d %d\n", c++, c, c++, c);
// result: 1 2 0 2
printf("%d %d %d %d\n", c++, c, c, c);
// result: 0 1 1 1

Answer 6

You are right: it is undefined. The reason is that, though it is guaranteed that the three arguments to printf() will be evaluated before printf() is called, the sequence in which the three arguments are evaluated is undefined.

It is technically incorrect that the incrementation occurs only after the semicolon, incidentally. What the standard guarantees is that the incrementation will occur no later than the semicolon. [Actually, in your case, I believe that the standard guarantees that it will occur before control is passed to the printf() function -- but now this answer is starting to spin off into realms of pedantic trivia, so let me let the matter rest there!]

Anyway, in short, you are right. The behavior is undefined.

Update: As @R.. rightly observes, the undefined behavior comes from the lack of a sequence point between arguments. The standard is quite careful regarding the participles unspecified and undefined, so the correction is accepted with thanks.