in our college we have a repeated C aptitude question... which goes like this....

int i=5
printf("%d %d %d", i--,i,i++)

and the answer given to us was 5,6,5.... when asked it was said that the compiler evaluates printf from right to left...... can somebody throw some light on how this statement gets evaluated.....

The correct answer is that the result is undefined, or unpredictable. It depends on the compiler -- the answer by some compilers may be 5,5,5 because only the last version is stored. Yet other compilers, such as VC++ 2005 Express will give 6,5,5.

Comments
Thanks for explanation. It opened some good teaching time.

The correct answer is that the result is undefined, or unpredictable. It depends on the compiler -- the answer by some compilers may be 5,5,5 because only the last version is stored. Yet other compilers, such as VC++ 2005 Express will give 6,5,5.

And others will give you 6, 6, 5 like it should be.

Right to left.
First variable evaluated is the i++. ( i = 5 ) 5 is assigned for the right most %d.
It gets incremented to 6 before is evaluated again. ( i = 6 ).
Next %d gets 6 assigned to it. Not incrementation here.
Last %d gets 6 because the decrement is after being assigned to be printed.
That's how I see it.
6, 6, 5

My understand in that i++ means the incrementation should be completed after the particular line of code (maybe the printf complicates things). Where ++i means to complete the statement before. So I would have thought the result should be 5, 5, 5 and then i++-- ... which is just 'i=5' before the next line of code.

EDIT: Well this got me curious, GCC gave me 6, 6, 5 as others have suggested.

Only Ancient Dragon has the correct answer. You cannot ++ or -- the same variable in the same statement. The C Standard says doing so is undefined and not guaranteed to give the answer you expect. See this and this.

Comments
Good FAQ links

> Only Ancient Dragon has the correct answer.
He should have stopped at the end of the first sentence IMO. Attempting to rationalise or explain any apparent results doesn't help.

> in our college we have a repeated C aptitude question... which goes like this
> and the answer given to us was 5,6,5
Find another college, or another tutor. The one you have doesn't have a clue.

No doubt your head is being filled with non-standard / implementation specific mush like how to rationalise UB for your current compiler. You're in for a lot of surprises when you pick up another compiler and find that much of what you've been taught isn't actually usable at all.

This is probably just a case of the professor trying to scare kids by using code in a way it generally won't be used. If your professor does insist that is the answer and won't budge, just listen to his explanation and remember his rules for the duration of the course. After you pass the course, you can go back to using code as it should be used.

Hi,
Before go to perform the statement execution you should fix these two concepts
In your mind
1. Normally both increment and decrement operation’s performed in two ways. Pre- increment/post-increment and pre-decrement/post-decrement. If you declare the variable I =5 then if you want to perform I++ operation in C first the value 5 will be stored into I after assigning only it will be incremented as 6. So in next statement only I value should go to value 6.
2. The next one is precedence of the operator’s. You must consider the priority of all the operators. The precedence has the order like
High priority: * / %
Low priority: + -
Another one to understand is
For this entire operator it should give the high priority for which one statement has the ( ) operator like (operators + operands). If one statement has this entire operator in the same line then it should perform operation from left to right.
Like this only printf function should perform, so for your program you got the result like 6, 6, and 5.
Int i=5;
I++ ( I=5) // I value assigned the next line will be incremented
I (I=6) // incremented value only assigned
I—( I=6) // after assigning the value 6 then only it’ll decrement the value to 5


ans:6,6,5;

Comments
Precedence has nothing to do with side effects, this is not an explanation.

> 2. The next one is precedence of the operator’s.
Someone else needs to read http://www.c-faq.com/expr/index.html in great detail, to learn about when side effects happen, and what a sequence point is.

Precedence has nothing to do with when side-effects happen.
Given f() * g() + h() what is sure is that the multiply will happen before the addition, but there is NOTHING which prevents the compiler from calling h() first and storing the result in a register.

Just because your assumptions match what your current compiler seems to do (aka "works for me") is not a valid explanation of how the language (or any other compiler) is going to treat the same code.

in our college we have a repeated C aptitude question... which goes like this....

int i=5
printf("%d %d %d", i--,i,i++)

and the answer given to us was 5,6,5.... when asked it was said that the compiler evaluates printf from right to left...... can somebody throw some light on how this statement gets evaluated.....

yaa...itz right..the printf statement evaluates from right to left....
letz start from right....
itz like
printf("%d",i++)
in this statement the value of i will be five because we are post incrementing i that is at this line i++means...i=i...and at the next line only i will be incremented by 1 i.e(i=i+1)...so output is 5...

next printf("%d",i)
in this statement the value of i will be 6...as it gets incremented by++ operator in the previous line...so 6 will be printed...

next printf("%d",i--)
in this statement the value of i will be 6 only not 5...i think the answer given to you is wrong...and the i will be operated by -- operator at next line only....hence the output is 6...according to your output the question must be printf("%d,%d,%d",--i,i,i++)
hope you are clear..bye...

Comments
You're way off target on this one, stop trying to rationalise undefined behaviour

> .i think the answer given to you is wrong.
Yes, just as wrong as yours is.
"it was a work of art - flawless, sublime. A triumph equalled only by its monumental failure" - The Architect.

Until you truly understand undefined behaviour (UB), you'll always struggle to come up with increasingly bizarre explanations of what is happening.

Only when you understand what UB really means will you realise that attempts at explaining it are pointless. All such explanations are simultaneously
- right ("works for me, today, with this compiler and this bit of code")
- wrong ("doesn't work for someone else")
- useless ("doesn't help anyone in the long run anyway")

Do the world a favour and read the C.L.C FAQ link I posted a couple of replies ago from end to end, and make sure you really know what UB and "sequence points" are.

Here's something to wrap your noodle around.

#include <stdio.h>

#define MUL(x,y) ((x)*(y))

int mul ( int x, int y ) {
    return x * y;
}

int main ( void ) {
    int a = 22;
    int b = 22;
    int r1 = MUL(a++,a++);
    int r2 = mul(b++,b++);
    printf("%d %d\n", r1, r2 );
    return 0;
}

$ gcc -W -Wall -ansi -pedantic foo.c && ./a.exe
484 506

It's the same code apparently, so why the different answers when compiled with gcc?

Comments
Thanks for the example.

It's the same code apparently, so why the different answers when compiled with gcc?

Because we just entered The Outer Limits?.
Darn it!. I knew my tax software was cheating me.

HEy every one its answer is 5,6,6 because in printf evaluation is done from right to left. firstly it will print i and then increment it(post increment operator), then it will print the incremented vallue that is 6 now(i), then for post decrement operator it will first print the value then it will decrement it so 6 will be printed.

Comments
Read the damn thread!!!!

this code displays different solutions on different compilers. Both showed me different answers.
So i too feel it as an undefined behaviour.

That this is undefined behavior isn't a matter of any debate or opinion; it is defined as such by the language standard, as WaltP stated more than 4 years ago.

Could someone please close this thread?

AFAICT, we've unfortunately lost the ability to close threads... It's at least marked solved, so maybe more braindead responses won't be added... We'll see.

AFAICT, we've unfortunately lost the ability to close threads...

As a moderator you can close the thread by editing it and checking the "This Article is Closed" check box.

This question has already been answered. Start a new discussion instead.