This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc…)
Code 1:
main()
{
int a=5;
printf("Value : %d %d %d %d\n",a++,a++,++a,a++);
}
ANS:
Value : 8 7 9 5
Code 2:
main()
{
volatile int a=5;
printf("Value : %d %d %d %d\n",a++,a++,++a,a++);
}
ANS:
Value : 8 7 7 5
Code 3:
main()
{
int a;
scanf("%d",&a);
printf("Value : %d %d %d %d\n",a++,a++,++a,a++);
}
INPUT is 5
ANS:
Value : 8 7 7 5
How the above programs are getting different outputs ?
I experimented volatile variable , it is used to prevent compiler optimizations.
So I understood the Code 2. But I want to know that ,how the Code 1 and 3 are working ?
volatile is to tell the compiler to read the value from memory every time as opposed to do any caching of values as part of its optimizations.
Your code exhibits undefined behaviour which is not going to be changed in anyway by using volatile.
What you have is an Undefined Behavior.
Your code modifies a variable more than once without an intervening sequence point.
You cannot use this code to draw any conclusions. It assures only one thing: that the output is Undefined.
This answer of mine explains in detail why this is undefined behavior. Note that though the answer is for C++, exact same reasoning and specifications exist for C as well.
what is the difference between volatile and local variable in c?
Using the keyword volatile tells the compiler to restrain from any optimizations by use of register caches.
Good Read:
Herb Sutter's excellent artile "volatile vs. volatile"
It's undefined behavior. No one can predict the correct output of the
printf("%d %d",a++,++a);
which one is executed first whether a++ or ++a so it's different output for different compiler or different scenarios.
Related
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 1 year ago.
I'm not able to understand, why this code produces this output. Can anyone help me with this??
#include <stdio.h>
int main( void )
{
int num = 5;
printf( "%d %d %d", num, ++num, num++ );
}
The output will be 7 7 5 (and NOT 5 6 7)
Making side effects happen in the same order as in some other compiler.
It is never safe to depend on the order of evaluation of side effects. For example, a function call like this may very well behave differently from one compiler to another:
void func (int, int);
int i = 2;
func (i++, i++);
There is no guarantee (in either the C or the C++ standard language definitions) that the increments will be evaluated in any particular order. Either increment might happen first. func might get the arguments ‘2, 3’, or it might get ‘3, 2’, or even ‘2, 2’.
https://gcc.gnu.org/onlinedocs/gcc/Non-bugs.html
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 4 years ago.
I think the best way to describe the problem is to actually show the output of this simple code:
Image contains code and output
#include<stdio.h>
int main()
{
int a=5,b;
b=a-++a;
printf("%d %d",a,b);
return 0;
}
As you can see, the values returned are logically correct.
++a increases the value of a to 6. Then b=6-6=0.
However, when I take the value of 'a' as user input using scanf, the following happens:
Image contains code and output
#include<stdio.h>
int main()
{
int a,b;
scanf("%d",&a);
b=a-++a;
printf("%d %d",a,b);
return 0;
}
Shouldn't the results be identical or am I missing something simple here?
The form a - ++a has an undefined value because the order of executions of the argument of '-' is undefined.
In the first case the compiler knows the value of a so it can optimize the code and finally all is known at compile time, not in the second case.
The fact the value is not the same when computed at compile time or execution time is a consequence of the form a - ++a whose result is undefined.
This question already has answers here:
Parameter evaluation order before a function calling in C
(7 answers)
function parameter evaluation order
(5 answers)
Closed 7 years ago.
Today I saw an anonymous behavior of the printf() function.
Can anybody please tell me why its behaving so.
Is that the execution of functions inside printf() is in reverse order?
Please explain this or share a helpful link.
MY CODE
#include <stdio.h>
int fun(){
static int c=15;c++;
return c;
}
int main()
{
printf("%d %d %d",fun(),fun(),fun());
}
Actual output : 18 17 16
Expected output : 16 17 18
EDIT 2:
I more thing I noticed that its behavior is not only with functions but also with variables
#include <stdio.h>
static int c=15;
int fun(){
c++;
return c;
}
int main()
{
printf(" %d %d %d %d %d",c,fun(),fun(),fun(),c);
}
Actual output : 18 18 17 16 15
Expected output : 15 16 17 18 18
Thanks in Advance :)
The order of evaluation of the parameters is unspecified. That means that it is dependent of the compiler implementation. The actual order from your example seems to be:
printf("%d %d %d",fun(),fun(),fun());
/* (3) (2) (1) */
but this is arbitrary and could well be any one out of the 6 possibilities.
int main()
{
int a, b, c;
a = fun();
b = fun();
c = fun();
printf("%d %d %d", a, b, c);
}
And you get what you need.
The parameter evaluation order is under compiler's control but the statement evaluation order is under your control.
This behavior seen because of the static variable. You may know A static variable inside a function keeps its value between invocations.
So the variable changed by the earlier call to the function fun() remains for the later call to the function. And the reason for the disordering of the values is -
The order that function parameters are evaluated is an unspecified behavior. It is only ensured that all parameters must be fully evaluated before the function is called.
You may have a look this link for some common undefined behavior in C and C++
A similar question was asked here:
Parameter evaluation order before a function calling in C
Essentially, the compiler is free to evaluate parameters to a function in any order.
When asked about common undefined behaviours in C, one user answered with this, which also answers your question.
The order in which the parameters to a function in not defined in the standard, and is determined by the calling convention used by the compiler.
You can refer this
I run the program, and get an output 18 17 16.
That means the different fun()'s run from the right to the left.
However, it is still an undefined behaviour. The order of them is not defined clearly in C, and it depends on the compiler.
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 7 years ago.
I am executing this c program on gcc compiler and getting strange results.
So how is it possible
code:
#include<stdio.h>
int main()
{
int i;
i =10;
printf(" %d %d %d ",i++,i++,i); //output : 11 10 12
return 0;
}
as per me result should be 10 11 12 but I am getting 11 10 12.
How is it possible?
In C++, the order of evaluation of function arguments is undefined so if you use the increment operator multiple times in the argument to a particular function there is no 'correct' answer, they may be evaluated in any arbitrary order.
Please familiarize yourself with the concept of Sequence points. Only at such defined sequence points is guaranteed that all side effects of previous evaluations are performed. There are no sequence points between the list of arguments of a function. So, it leads to undefined behavior.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Could anyone explain these undefined behaviors (i = i++ + ++i , i = i++, etc…)
int main()
{
int a=5,s;
s=++a + ++a;
printf("%d",a);
printf("%d",s);
}
output is 7 and 14
BUT
int main()
{
int a, s;
printf("Enter value of a");
scanf ("%d",&a);
s=++a + ++a;
printf("%d",a);
printf("%d",s);
}
input user gives is 5
output is 7 and 13
WHY?
Undefined behaviour:
s=++a + ++a;
Anything can happen when undefined, so your behaviour is perfectly valid.
I'd suspect this is an artifact of compiler optimisation, in the first example a is known so the compiler optimises the preincrements to occur before the addition. In the second example the value is unknown and the compiler does not optimise the sequence causing it to complete left to right. This may be a function of your specific compiler and it would need to be looked at specifically.
Undefined behaviour. Change it, or you risk being attacked by raptors.
hi budy this coding working correctly in VI compiler ..