This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc…)
Consider, following 2 coding lines in C
int a=0;
printf("%d%d%d%d",++a,a+1,a++,++a);
in visual C++, it gives
output:3431
But in Turbo C++
gives:
output:3311
This is also compiler dependent?
The C specification does not specify the order that the arguments to your function will be evaluated, so there's no guarantee what output you will get.
Related
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Undefined behavior and sequence points
(5 answers)
Closed 3 years ago.
The following C code executes correctly but not as expected. Post increment operator here in z=z++ is creating confusion here. I may not be able to figure out silly mistake/concept, Can I have a brief explanation or some helpful link please.
#include<stdio.h>
int main()
{
int x=5,y=6,z=7;
if(x-y)
z=z++;
z=--z;
printf("%d",z);
}
You are not allowed to do z=z++; because between 2 sequence points you are not allowed to assign a variable 2 times.
This one is a full expression in which you assign z 2 times. So it can be interpreted ambigously and the result of the C abstract machine is undefined behavior.
The same for z=--z.
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 6 years ago.
I am trying the following code:
#include <stdio.h>
int main()
{
int c =0;
c -= --c - c++;
printf("%d \n",c);
return 0;
}
When I compiled and run it using a online c complier (https://www.tutorialspoint.com/compile_c_online.php) the result is -1. But I expected it to be 0.
So, I try it on my local Dev C++ (Windows) and the result is 0.
Should the result be 0 ?
If so, why 2 gcc compilers (ok they are in different plataform) gives me 2 different results ?
I ve been looking for some kind of automatic flag otimization which could produce a different result but I had no success.
THIS IS UNDEFINED BEHAVIOR (3 modifications without sequence points inbetween to the same variable)
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 8 years ago.
main()
{
int a=10;
printf("%d\t%d\t%d\t%d",++a,--a,a--,a++);
getchar();
return 0;
}
While running this program in Visual Studio 2012, I am getting the output: 10 10 11 10.
While running this program in Turbo C, I am getting the output: 10 9 11 10
The second output(Turbo C) seems correct from the point of view that parameters are scanned from right to left, evaluated and put onto stack.
But i am sure that the output from Visual Studio also can't be wrong. So, why this difference in output?
The order of evaluation of arguments is not defined, that is, the compiler can evaluate them in any order(according to the standard).
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Undefined, unspecified and implementation-defined behavior
(9 answers)
Closed 9 years ago.
int main()
{
int i=2;
printf("%d, %d\n", ++i, ++i);
return 0;
}
can some one explain me.
when it compile on turbo c its output is 4,3
and use GCC then it is 4,4;
why this output changes with respect to the compiler
This is undefined behavior, the compiler can do whatever they want.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc…)
i tried this simple C program in GCC
#include<stdio.h>
int main(){
int x=5;
printf("%d,%d,%d,%d,%d",++x,x++,x,x++,++x);
return 0;
}
and the output was 9,7,7,6,6
i traced it and assumed that it will print 6,6,7,7,9 but i found my assumption in reverse order, how come!
Because your program has undefined behaviour. There is no sequence point between the evaluations of function arguments, and it is undefined behaviour to mutate the same object more than once without intervening sequence point.
The program is simply ill-formed. It is not a valid C program.