This question already has answers here:
How #define work? Strange result for CUBE(y) y*(y*y)
(4 answers)
Closed 8 years ago.
I was going through my C learning by writing small pieces of code and one new question came up
I have written a small piece of code
#include<stdio.h>
#include<conio.h>
#define SUM(a) (a+a)
main()
{
int w,b=5;
w=SUM(b++);
printf("%d\n",w);
printf("%d\n",b);
getch();
}
What i was thinking that it will display the output as
10
6
but it is showing
10
7
Can someone explain why ,i am using Visual Studio 2008
because when you do
w=SUM(b++);
the macro will be replaced by:
w= b++ + b++;
now, if b=5 then you do twice b++ and get b=7
Edit
after reading MSalters comment i did some searching and found out that as he said this code couse UB.
as says here:
If a side effect on a scalar object is unsequenced relative to either
a different side effect on the same scalar object or a value
computation using the value of the same scalar object, the behavior is
undefined. If there are multiple allowable orderings of the
subexpressions of an expression, the behavior is undefined if such an
unsequenced side effect occurs in any of the orderings.
Related
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Parameter evaluation order before a function calling in C
(7 answers)
Closed 1 year ago.
Can someone please explain why the output here is 2 1 1, what does c prioritise here? how come the output of i++ is 1. Thanks in advance
~
#include <stdio.h>
void main(){
int i=1;
int *p=&i;
printf("%d%d%d\n",*p,i++,i);
}
The behavior of this code is not defined by the C standard per C 2018 6.5 2:
If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined…
i++ has the side effect of updating i with its incremented value. The function call arguments also include *p and i, both of which refer to i and use its value. i is a scalar object. The order of evaluation of function call arguments and their side effects are unsequenced (meaning the C standard does not impose any ordering requirements on them). Therefore, all the conditions for the rule above are met, so the behavior is not defined by the C standard.
This question already has answers here:
printf and ++ operator [duplicate]
(5 answers)
Closed 3 years ago.
I tried running this program :
#include<stdio.h>
int main(){
int a=5;
printf("%d %d", ++a,a++);
return 0;
}
with gcc in arch-chroot on a armv7 device. I expect to get output 7 5 but i'm getting 7 6. Can anyone explain what's going on?
Your code is invoking Undefined Behavior (UB)!
Use the warning flgas -Wall -Wextra during compilation, and the compiler will tell you the story:
prog.c: In function 'main':
prog.c:4:30: warning: operation on 'a' may be undefined [-Wsequence-point]
4 | printf("%d %d", ++a,a++);
| ~^~
7 5
In that online demo, I got a different output, a characteristic of UB.
Read more in printf and ++ operator.
6.5p2
If a side effect on a scalar object is unsequenced relative to either
a different side effect on the same scalar object or a value
computation using the value of the same scalar object, the behavior is
undefined. If there are multiple allowable orderings of the
subexpressions of an expression, the behavior is undefined if such an
unsequenced side effect occurs in any of the orderings.84)
++a and a++ are unsequenced. Your program is ill-formed.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 8 years ago.
Here is a code
#include<stdio.h>
int main()
{
int i=5;
printf("%d%d",++i,++i);
}
I am not understand, why the output is 77?
++i and i++ are expressions that have side effects. Using two of these in the same expression results in undefined behavior. Basically, anything goes.
Specifically, I'm guessing the compiler says you want to increment i twice and then use the result, so it evaluates ++i twice, resulting in 7, and then sends that to printf.
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 9 years ago.
int a[]={10,20,30,40};
int x=0;
int v=a[++x]+ ++x + a[--x];
printf("%d",v);
What will be the output of this program??
Completely confused with the output. No way it is going to be done according to my operator precedence knowledge.
According to me, in this expression Array subscripting [] has highest precendence and should be executed first. so both [] should be executed first from left to right. In this case value of x will increment first, then decrement and finally come back to 0. so expression will become int v=a[0] + ++x + a[0]. Then the pre increment is having highest precedence and it will be incremented to 1. so our expression will become int v=a[0]+1+a[0]. so final output will be 21.
But this is not the case. I have checked on different compiler implementations and no one prints 21.
I am much surprised because the value printed is 43, which is no where understandable to me. That's why I want someone to help me understand and come to the result 43.
The link which others have suggested is using only increment and same rvalue and lvalue cases. But this is somewhat different and not clear. I tried to contruct expression tree for this and solve but 43 is no where in scope.
Output of this code:
int v=a[++x]+ ++x + a[--x];
is undefined and it depends on the compiler implementation.
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 5 years ago.
I came across a very interesting fact while executing the following a simple c program:
#include<stdio.h>
int main( )
{
int k=0;
printf("%d%d%d", k++, k, ++k);
return 0;
}
in windows it was showing output as: 1 1 1
but in linux(ubuntu) it was showing as: 1 2 2
why is it so?
It's undefined behaviour. When there are no / ambiguous sequence points. See this wikipedia article:
http://en.wikipedia.org/wiki/Sequence_point
There are two problems. First is that the order in which the expressions k++, k, and ++k in the printf call are evaluated is not specified; the compiler is free to evaluate them in any order it sees fit. Second is that an object may not have its stored value updated more than once between sequence points by the evaluation of an expression. Both k++ and ++k attempt to update the value stored at k, and there is no sequence point between those expressions, so the behavior is undefined; any result is permitted.
The standard does not specify an ordering in which the arguments of a routine are evaluated.
Writing code that depends on the ordering is not portable.