-1

While solving some aptitude questions on C programming language and I encountered a problem in which I have to tell the output. The program is :-

#include<stdio.h>
int main()
{
    int x = 5;
    printf("%d %d %d", ++x, x++, ++x);
    return 0;
}

Now from my previous knowledge I know that the parameters of a printf() function are evaluated right to left. So solving this manually I'm getting output as :- 8 6 6

But the when I compiled this program I got the output as :- 8 6 8

Okay here is the question that seems bit related to this question but, there I'm specifically asking for the execution of parameters in the function not for the assignment operators.

Or does the execution of parameters happens randomly? If so, then some time it should give some different output but it is not giving. Even on different compilers it is giving the same output as 8 6 8.

why this anomaly?

Thanks

Community
  • 1
  • 1
  • even the wording 'from right to left' is wrong. HPUX evaluated from left to right. – Peter Miehle Dec 08 '15 at 12:23
  • @PeterMiehle is this evaluated from left to right? –  Dec 08 '15 at 12:24
  • 1
    BTW the referred-to question is about sequence points in assignments; not sequence points when evaluating function arguments. – joop Dec 08 '15 at 12:25
  • it is 'side effect'. everything can happen – Peter Miehle Dec 08 '15 at 12:25
  • I edited this question, please can any of you just try to answer in very short or in the comments only –  Dec 08 '15 at 12:35
  • 1
    Ask @juanchopanza he selected the wrong duplicate. – Karoly Horvath Dec 08 '15 at 12:42
  • okay great, thanks a lot for your support –  Dec 08 '15 at 12:42
  • I re-opened, but it is the same phenomenon. There are no sequence points so you get UB. – juanchopanza Dec 08 '15 at 12:53
  • 1
    The order in which function parameters are evaluated and the order in which the side effects of those evaluations are applied is *unspecified*; thus, it's not guaranteed that`++x` is evaluated before `x++` or that the side effect is applied immediately after evaluation. All that's guaranteed is that the three arguments are evaluated before the function body executes. The behavior is *undefined* so the compiler is not required to handle the issue in any particular way. – John Bode Dec 08 '15 at 13:41
  • Related: http://stackoverflow.com/q/4176328/694576 – alk Dec 08 '15 at 15:09

3 Answers3

3

The order of evaluation in printf() is not left to right as you assumed. The evaluation order is unspecified:

From C11 draft (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).

From, 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.

So the three x++ expressions can be evaluated in any order. But this leads to undefined behaviour as you are attempting to modify the same object more than once without an intervening sequence point. The comma in a function designator is a separator, not the comma operator. Because comma operator does introduce a sequence point between its operands.

P.P
  • 117,907
  • 20
  • 175
  • 238
2

The behavior is definitely unexpected, You are not supposed to change the value of a variable more than once in a function call. Rules of sequence points. Try looking at this link. And also read about sequence points in a program

Just try not changing the value of one variable more than once in a function call

Community
  • 1
  • 1
sameera sy
  • 1,708
  • 13
  • 19
1

There are two things interfering here:

  • the order of evaluation of function arguments is undefined (causing undefined results) -> the order can be anything because there is no order imposed by The Standard (The standard says: the order is unspecified)
  • there are no sequence points between the evaluations of the function arguments. (the function calling per se, and its return are sequence points, but that's irrelevant here)

What this means in practice: because the evaluating of the function arguments has side effects (the increments) there are multiple attempts to alter x's value without an intervening sequence point, causing Undefined Behaviour.

joop
  • 4,330
  • 1
  • 15
  • 26
  • Order of evaluation of function arguments is actually unspecified, not undefined. – P.P Dec 08 '15 at 13:18
  • The (intended) behaviour is (defined as) "not specified" by the Standard, so the actual order that we observe is undefined. – joop Dec 08 '15 at 13:28
  • 1
    *Unspecified behaviour* doesn't automatically lead to *undefined behaviour*. E.g. `printf("%d %d %d\n", f(), g(), h());`. The order of evaluations of the three functions are unspecified but there's no undefined behaviour. – P.P Dec 08 '15 at 13:33
  • It's not just that the order in which arguments are evaluated is unspecified, the evaluation can also be interleaved. And since x is modified three times without intervening sequence point, _that_ is undefined which means _anything_ can happen. Like a crash with massive data loss when a customer uses the software, after it worked fine all the time on your development machine. – gnasher729 Dec 08 '15 at 13:35
  • @l3x I never said that. at gnasher: yes, that's what I said, maybe should first read, before reacting? – joop Dec 08 '15 at 13:40
  • @joop You didn't say that. But your answer: *the order of evaluation of function arguments is undefined * and comment: *The (intended) behaviour is (defined as) "not specified" by the Standard, so the actual order that we observe is undefined* certainly imply that and I gave you a counter example. (bye). – P.P Dec 08 '15 at 13:43