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.
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:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 5 years ago.
I have seen in this site that prefix increment or postfix increment in a function call may cause undefined behavior. I have gone through one of those recently. The source code is something like this :
#include <stdio.h>
void call(int,int,int);
int main()
{
int a=10;
call(a,a++,++a);
printf("****%d %d %d***_\n",a,a++,++a);
return 0;
}
void call(int x,int y,int z)
{
printf("%d %d %d",x,y,z);
}
The output comes out as 12 11 12****14 13 14***_. But, when a is printed first in the function, shouldn't it be 10? Why does it become 12? Also, why does a++ decrease from 12 to 11? Can someone please kindly explain? Thank you.
There are two things your example code requires us to consider:
The function arguments order of evaluation is unspecified. Therefore, either ++a or a++ is evaluated first but it is implementation-dependent.
Modifying the value of a more than once without a sequence point in between the modifications is also undefined behavior.
Because of point 2, you have double undefined behavior here (you do it twice). Note undefined behavior doesn't mean nothing happens; it means anything can happen.
call(a,a++,++a); /* UB 1 */
printf("****%d %d %d***_\n",a,a++,++a); /* UB 2 */
That is undefined behaviour and as such it is entirely up to the implementation of the compiler in which order the following operations are done:
submit argument a
submit argument a++
submit argument ++a
increment a for ++a
increment a for a++
The only thing that the compiler knows is: 2. has to happen before 5. and 4. has to happen before 3.
You are observing:
++a;
submit argument 2
a++;
submit the other arguments
The C and C++ standards do not indicate an order of evaluation for function arguments. To be blunt, it is not incorrect for a compiler to cause the parameters to be evaluated from right to left, or left to right.
The best answer is, Stay Away from this type of 'Undefined Behavior'; as it can lead to subtle portability problems.
There's no requirement that a be equal to anything; that's what is meant by undefined behavior. It's entirely up to the compiler to evaluate the arguments to call and to printf in any order it sees fit, because the language does not specify what order they need to be evaluated.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 6 years ago.
the code is given below:
it gives output true2.
#include<stdio.h>
int main()
{
int a=10;
if(a==a--)
printf("true 1\t");
a=10;
if(a==--a)
printf("true2 \t");
return 0;
}
The comparison done in both of the if statements result in undefined behaviour. So, anything could happen. Because a is read and modified without an intervening sequence point. The comparison operator == doesn't introduce a sequence point. You probably need to learn about undefined behaviour and sequence points, etc to understand the problem better.
Modern compilers may also help you. For example, Clang issues:
warning: unsequenced modification and access to 'a' [-Wunsequenced]
if(a==a--)
~ ^
warning: unsequenced modification and access to 'a' [-Wunsequenced]
if(a==--a)
~ ^
for the two if statements (GCC also produces similar warnings with gcc -Wall -Wextra).
In general, it is not a good practice to do a-- (or --a) inside a condition, because it is not clear to read.
In order to understand the difference between a-- and --a please see the answer at: Incrementing in C++ - When to use x++ or ++x?
This question already has answers here:
Order of operations for pre-increment and post-increment in a function argument? [duplicate]
(4 answers)
Undefined Behavior of Postfix or Prefix Increment in Function Calls in C [duplicate]
(4 answers)
Is the output of printf ("%d %d", c++, c); also undefined?
(6 answers)
Closed 7 years ago.
print(int*a,int*b,int*c,int*d,int*e){
printf("\n%d %d %d %d %d %d",*a,*b,*c,*d,*e);
}
main(){
static int arr[]={97,98,99,100,101,102,103,104};
int *ptr=arr+1;
print(++ptr,ptr--,ptr,ptr++,++ptr);
return 1;
}
O/P: 100 100 100 99 100 (some -ve values) on GCC & turbo C
According to my understanding, the ptr points to 98 first, then ++ptr is passed which makes it to point 99.How in the world it prints 100? Even then, it does not decrements the ptr till 3rd argument and prints it again.What's going on?
Whow ! Your print function has 6 %d, and you only pass 5 int values => undefined behaviour
You are modifying more than once ptr in a single call (*) => undefined behaviour
I would say that the compiler can do anything without you can say it is wrong ...
(*) the order of the operations in a single instruction is undefined (except some explicit cases) : 6.5 §2-3 : Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression. and Except as specified
later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation
of subexpressions and the order in which side effects take place are both unspecified.
The above code will result multiple warnings which may lead to undefined behaviour in multiple systems
print(++ptr,ptr--,ptr,ptr++,++ptr);
multiple unsequenced modifications to 'ptr'
[-Wunsequenced]
because in my compiler it is giving output as below :
99 99 98 98 100 0
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.