This question already has answers here:
order of evaluation of function parameters
(5 answers)
C/C++ - evaluation of the arguments in a function call [duplicate]
(5 answers)
Closed 2 years ago.
I have the following program:
#include <stdio.h>
int main ()
{
int x = 8;
printf("%d %d %d ", x++, x << 2, x >> 1);
}
The way I feel like this is supposed to go is this way:
The first number should be 8. Then it gets incremented to 9. 9<<2 is 36 so the second %d is 36. The last one is 8 >> 1 which is 4.
However, when I put this into the compiler I get '8 32 4' and not '8 36 4'.
Can someone explain why please?
Thank you!
This operation invokes an Undefined Behavior.
The gcc executes the way you observe, clang does it another way as the result of this program is undefined.
clang also issues a warning
https://godbolt.org/z/GzhPKn
The make program result defined:
int main ()
{
int x = 8;
x++;
printf("%d %d %d ", x, x << 2, x >> 1);
}
Argument evaluation order in C and C++ is undefined. Whether the increment or one of the shifts happens first depends on implementation and compiler optimization. It is never advisable to write code like this.
int a() { printf("A"); return 0; }
int b() { printf("B"); return 0; }
int c() { printf("C"); return 0; }
If you do:
printf("%d%d%d", a(), b(), c());
It doesn't necessarily mean you'll get an ABC on your console. Ignore the 0s.
Related
This question already has answers here:
Implicit int return value of C function
(7 answers)
Closed 4 years ago.
Running a recursive function such as this one (compiled in gcc 7.3.1):
#include <stdio.h>
int arr[] = {5,1,2,6,7,3};
int arraySize = 6;
int recfind(int value, int index)
{
if (arr[index] == value)
return 1;
if (index >= arraySize)
return 0;
// return recfind(value, ++index);
recfind(value, ++index);
}
int main() {
printf("found 6? %d\n", recfind(6, 0));
printf("found 9? %d\n", recfind(9, 0));
}
I get the following output:
found 6? 1
found 9? 0
Why does this work? Since the result of the recursive recfind call is not returned, how is the return value of higher-level calls chosen?
For C section is 6.9.1 from N1256:
If the } that terminates a function is reached, and the value of the
function call is used by the caller, the behavior is undefined.
So the behaviour of your program is undefined.
Why does this work?
There is a possibility that the target + compiler you are using doesn't tamper the register containing the return value from last (recursive) function call. C doesn't mandate this mechanism for returning value in specs.
So, though it may sound sensible, this is not guaranteed.
This question already has answers here:
unexpected output in C (recursion)
(3 answers)
Closed 7 years ago.
#include <stdio.h>
int main()
{
static int i = 5;
if(--i){
main();
printf("%d,", i);
}
return 0;
}
I'm unable to find why the value of i is becoming 0 every time.
There is a recursive call to main() in your code, till if(--i) is not down to 0. The print statement does not get a chance to execute.
Once i becomes zero, the control returns, and the value of i, is, well, 0, then.
[I don't have a photo editor handy right now, sorry],
Try to have a look at the rough graphics to get an idea.
FWIW, i is having static storage, so it holds the value across function calls.
(I assumed the last part is already understood, just adding for sake of clarity.)
here's your program's execution and values:
i = 5; --i; main ()// i==4
i = 4; --i; main ()// i==3
i = 3; --i; main ()// i==2
i = 2; --i; main ()// i==1
i = 1; --i; // i == 0 ,main is not called!
and only then the program comes back from recursion:
printf("%d,", i);
This question already has answers here:
what does the - operator do with char *?
(4 answers)
Closed 9 years ago.
#include <stdio.h>
int main()
{
short int a = 5;
printf("%d" + 1, a);
return 0;
}
The code prints the alphabet enclosed in quotes in printf irrespective of the value and type of variable a. If any other number is added except 1 nothing gets printed.
Why is it so?
Not sure, I would expect it to print just d, of course. That's what happened when I tested it.
If you add more than 1 (or 2) all bets are off and you're getting undefined behavior for passing a random pointer instead of a valid formatting string.
On compiling the above code, you should get a warning like:
[Warning] too many arguments for format [-Wformat-extra-args]
Now remove the printfs argument a.
printf("%d" + 1);
This will print d.
100 101
% d
^
|
Here is the starting address of the string.
%d is a string and its starting address is 100. "%d" + 1 will give you the address 101.
Why you want to do this?
if you want you can do like
do like
printf("%d", a+1);
Try this and you'll understand what unwind is trying to make you understand
#include <stdio.h>
int main()
{
short int a = 5,b = 4;
printf("%d %d" + 4, a,b);
return 0;
}
OUTPUT: d
Since it takes the 4th character inside the double quotes in printf() statement..
If number is 3
OUTPUT: 5
If number is 2
OUTPUT: 5
If number is 1
OUTPUT: d
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 9 years ago.
#include <stdio.h>
int main()
{
int x=100;
x=x++;
printf("x : %d\n",x); //prints 101
return 0;
}
What is the reason for output 101? I think output should be 100.
This is Undefined Behaviour, due to Sequence Points.
Between consecutive "sequence points" an object's value can be
modified only once by an expression
The end of the previous epxression x=100; is one sequence point, and the end of x=x++; is another.
Basically, your expression has no intermediate 'sequence points', yet you're modifying the value of X twice. the result of this is Undefined Behaviour: Basically, anything could happen: You could get 100, 101 or 42...
Here is what I believe you're looking for:
int main(){
int x=100;
printf("x : %d\n",x++); // Will print 100 and then increment x
return 0;
}
You're incrementing x before printing it - so this is the reason for the output 101.
You're doing the same operations as x = x; x++;
You're incrementing x after assigning it to x, effectively:
The x=x++ effectively becomes (assign x to x prior to increment) then (increment x)
This is going to give the same effect as if you were to wrote:
x = x;
++x; // Increment after the assignment
This should leave x as 101 after the x=x++; line.
You're incrementing the same x you're printing - here it doesn't matter whether post- or pre-incrementing.
x=x++ would produce the same result as x=++x.
If you would like to assign it another object do this:
#include<stdio.h>
int main(){
int x=100;
int y=x++;
printf("y : %d\n",y); //prints 100
printf("x : %d\n",x); //prints 101
return 0;
}
This is what is happening
#include <stdio.h>
int main()
{
int x=100;
x=x++; // This is original code however I have rewritten this as below
x=x;
x++;
printf("x : %d\n",x); //prints 101
return 0;
}
as you can see
x=x++;
can be rewritten as
x=x;
x++;
hence the result no surprises ...
The effect is that the value of x won't change.
x++ works like this:
Take a reference of the value.
Allocate a new integer and store the value into it.
Increment the reference.
Return the temporary integer.
In C++ it would look like this:
int PostIncrement(int& x)
{
int y = x;
x = x + 1;
return y;
}
The operator precedence is not lost in this way and the assignment is done after the increment.
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 4 years ago.
Possible Duplicate:
Parameter evaluation order before a function calling in C
For the below code I expected the output to be 20 and 76 but instead 75 and 21 is comming as output .Please explain why is so.
#include<stdio.h>
unsigned func(unsigned n)
{
unsigned int a =1 ;
static unsigned int b=2;
a+=b; b+=a;
{
unsigned int a=3;
a+=b; b+=a;
}
//printf("%d %d ",a,b);
return (n+a+b);
}
int main()
{
printf("%d %d\n",func(4),func(5));
return 0;
}
you are expecting func(4) to be called before func(5) but the opposite happens with your compiler. The order of evaluation of function parameters is unspecified by C standard. So, compiler is free choose which function to call first. So across different runs you may observe different order of function calls, though it's very unlikely to happen that way with the same compiler.
The order of evaluation of func(4) and func(5) isn't defined by the C standard(s).
The order of evaluation of expression is unspecified behaviour hence func(4) and func(5) may be called in different order as you supposed to
You might like to visit it for more
Compilers and argument order of evaluation in C++
Parameter evaluation order before a function calling in C
The arguments are pushed onto stack in reverse order. It seems in your compiler implementation, func(5) is called before func(4).
Order of evaluation could be the reason. Because,
//printf("%d %d\n",func(4),func(5));
printf("%d \n",func(4));
printf("%d \n",func(5));
prints
20
76
func(5) is getting executed first :
Values of variables after executing func(5) :
a = 3
b = 13
func(5) = 21
Since, b is static, the values after executing func(4):
a = 14
b = 57
func(4) = 75
The code is simple, and remember static variables will preserve their values between function calls.
In your program, due to your compiler(thus compiler specific, not defined by standards):
func(5) is executed first, : which returns 21..
explanation:
unsigned func(unsigned n) /*first with 5*/
{
unsigned int a =1 ;
static unsigned int b=2;
a+=b; b+=a; // a = 3, b = 5
{
unsigned int a=3;
a+=b; b+=a; // a = 8, b = 13
}
//printf("%d %d ",a,b);
return (n+a+b); // 5 + 3 + 13 = 21.
}
func(4) is executed next,
explanation:
unsigned func(unsigned n) /*first with 5*/
{
unsigned int a =1 ;
static unsigned int b=2;
a+=b; b+=a; // a = 14, b = 27
{
unsigned int a=3;
a+=b; b+=a; // a = 30, b = 57
}
//printf("%d %d ",a,b);
return (n+a+b); // 4 + 57 + 14 = 75(which is printed first).
}
Hence the output.
There is a well known term for this called "function side effects". You change a variable inside a function, call the function and rely upon a statement using the variable expecting it to have already changed. Generally this should be avoided and is not a good approach.
A better alternate in such a scenario is either call function and store the return values and then use them in printf or make two different printf calls.
side effects