multiple pre increment/post increment in expression of C language

Question

I would like to know the explanation for the following expression evaluation in C under windows TURBO c..

void main()

{

int i=4;

int x;

x= ++i + ++i + ++i; // i becomes 5 then 6 added becomes 11 and then incremented to 12 so 11+12=23

printf("%d",x);

getch();

}

when the above was executed value of x comes out to be 21

Slightly eliminating the x variable in the above

void main()

{

int i=4;

printf("%d", ++i + ++i + ++i); //accordingly at this step 5+6+7=18

getch();

}

when the above is executed the answer comes out to be 18

Can anyone provide a decent explanation step by step and why two answers are different???

Thanks in advance.

Akshay

michaelkellett · Answer

james.flynn wrote: you can step through the statement using the 'C Operator Precedence ' rules and determine the answer a compliant compiler would generate yourself. This really isn't right. A compliant compiler is one which is compliant with a specified standard. ISO/IEC 9899 ("C99"|) and as far as I know all subsequent ISO C standards specify things like: i = ++i + 1; a[i++] = i; as undefined. This means that a compiler may make any result it likes and still be compliant. MK

james.flynn · Answer

>James, you are on the right track and a good try.. And you actually ran the silliness. BUT to no avail, you did not understand the error message. Actually, I do understand the message and it is a WARNING not an ERROR. In fact, when you take this program and run it, the result is: 19. It didn't crash and burn or go puff. It didn't complain about 'i' as undefined or anything like that, in fact, it acted just like the warning it is. Now I'm not saying this is good programming practice or anything like that because it isn't. I don't basically disagree with what you are saying, I'm just pointing out that it isn't an error in the language spec. In fact, if you compile the code, you get a warning, but it does generate code (this is for an ARM Cortex-A7) that then executes: { int i=4; 44: e3a03004 mov r3, #4 48: e58d3004 str r3, [sp, #4] int x= ++i + ++i + ++i; 4c: e59d3004 ldr r3, [sp, #4] 50: e2833001 add r3, r3, #1 54: e58d3004 str r3, [sp, #4] 58: e59d3004 ldr r3, [sp, #4] 5c: e2833001 add r3, r3, #1 60: e58d3004 str r3, [sp, #4] 64: e59d2004 ldr r2, [sp, #4] 68: e59d3004 ldr r3, [sp, #4] 6c: e0822003 add r2, r2, r3 70: e59d3004 ldr r3, [sp, #4] 74: e2833001 add r3, r3, #1 78: e58d3004 str r3, [sp, #4] 7c: e59d3004 ldr r3, [sp, #4] 80: e0823003 add r3, r2, r3 84: e58d3000 str r3, [sp] printf("x(%d) = ++i + ++i + ++i;
",x); 88: e59d1000 ldr r1, [sp] 8c: e3000000 movw r0, #0 90: e3400000 movt r0, #0 94: ebfffffe bl 0 <printf> } When you run this code, the result is 'x=19'. So the code isn't ' uncompilable ' because I just compiled it, it ran and produced an output. That may not be the result you wanted or thought it should be because of the semantics associated with the sequence point rules in C and C++, but the assertion that the BNF supports your conclusion that it will not compile and result in an error is incorrect. Different compilers all utilize different parsers in their construction--LALR, LL, SLR, GLR--and each will parse this statement differently; some may and some may-not compile the code due to the compiler writers interpretation, but I avoid blanket absolute statements.

james.flynn · Answer

At this point the discussion really is a dead horse. I compiled the code with GCC v5.x--which is a Compliant compiler ( https://gcc.gnu.org/onlinedocs/gcc/Standards.html )--so your assertion that is it illegal and not compliant is flat out wrong. Rather than beating the horse, what I really want to highlight that people come to web-sites like element14 for primarily 2 reasons: (1) to get an answer to a question [I doubt they are going to come here to determine if their compiler is compliant] and (2) to find solutions to problems. I responded to this thread because it is promulgating incorrect information about the compliance/legality of a correctly (though idiotic) C expression, then attempted to validate that information by incorrectly citing BNF notation. The entire premises of the argument is invalidated by simply compiling the code segment and seeing that it does compile (though with a warning) and run. IMO, it is wrong to disseminate incorrect information as fact when it is really opinion.

multiple pre increment/post increment in expression of C language

Top Replies