** sorry, this is a basic question, but couldn't find the answer on Google **
In the following code, is it guaranteed that the "number" variable will point to the same value as assigned in the "f" function? Because I have the idea that "n" will be destroyed, so "i" will point to a random place, but when I run this code, it prints the right value.
Code:#include <stdio.h>
int *f() {
int *i;
int n = 15;
i = &n;
return i;
}
int main() {
int *number;
number = f();
printf("%d", *number);
return 0;
}
Sometimes you get lucky.
In this case, you got lucky because the computer does not actively destroy information, it merely sets it aside to reuse it. Since you didn't ask for more memory between it getting lost in the call to f and trying to print it, it was still there.
you're right, it's not correct.
You could make it static so that it's the same var whenever you call the function:Code:#include <stdio.h>
int *f() {
int *i;
static int n = 15;
i = &n;
return i;
}
int main() {
int *number;
number = f();
printf("%d", *number);
return 0;
}
The way to guarantee the variable will still exist in memory after the function f() has finished executing is to allocate space for it with a call to malloc().
You should also do some error checking. If malloc() fails, it will return NULL and the function above with then have troubles with the *i = 15 line. Also, if you have functions returning pointers to newly allocated spaces in memory, you need to keep track of these places and be sure to free() them when you are done using them. Only use free() on pointers that have been returned by malloc(), otherwise you'll get undefined behavior.Code:int *f() {
int *i; /* declare a pointer to an integer */
i = malloc(sizeof(int)); /* and assign it the address of a block of memory the
* size of one integer */
*i = 15; /* set the value of the integer pointed to by i to 15 */
return i; /* return the address of the integer */
}
To answer the original question: no!
Local (non-static) variables in functions are not guaranteed to exist when the function returns. Returning a pointer to a local variable therefore means the caller receives a dangling pointer (a pointer to something that is not guaranteed to exist). If the caller dereferences that pointer (as you do, in the printf() line) the result is undefined.
If you get the right results, you've just got lucky (or unlucky if you look at it correctly; you are led to believe the code is correct and it isn't). You are not guaranteed to get the same results with another compiler, an update of your compiler, putting more code into your program, .....
When you call a function (in this case f()). You add a new stack frame to the stack, which will contain the return variable, return address, function arguments and local variables. The stack pointer is then advanced by one to this stack frame (f function call) and the code is executed. When you call return, the return value will be set, and the stack pointer decremented and you go back to the calling function (main in this case). The stack frame is not explicitly destroyed. Only if you then called another function, would a new stack frame be pushed on the stack, which would likely overwrite anything that was there previously.
That's why you should never return anything that's local to a function, it *might* still be there, but you can't rely on it.
QuantumPete
To prove the point that this DOESN'T work, we can do this:Quote:
Originally Posted by lecter55
My guess, is that you will see 42 for both numbers, if it gets any predictable result at all.Code:#include <stdio.h>
int *f() {
int *i;
int n = 15;
i = &n;
return i;
}
int *g()
{
int *p;
int x = 42;
p = &x;
return p;
}
int main() {
int *number;
int *number2;
number = f();
number2 = g();
printf("%d, %d", *number, *number2);
return 0;
}
Edit: Fixed up the code to match g() with f() - thanks to QuantumPete for pointing out the bug.
That's interesting, I get 15 and 42 printed out...Quote:
Originally Posted by matsp
QuantumPete
Edit: and I see why, x in g() overwrites i in f(), which only hold the address of n, which is therefore still alive and kicking on the stack. After that call to printf, however, the values get scrambled.
> That's interesting, I get 15 and 42 printed out...
My guess is you're using gcc
If defer-pop is enabled, then your variable, which has gone out of scope, can last a bit longer than you might otherwise suspect.Quote:
Originally Posted by gcc manual
Just goes to show you that it's impossible to get a consistent answer out of UB :D
But defer-pop only applies to function arguments, not local variables within functions - it may however, well be that if optimization is sufficiently applied, it inlines both f() and g() into main() and allows both sets of variables to exist at once - it shouldn't use twice the stack-space. I think Quantumpete will agree that the updated [after QP's post] code "works" in the "correct broken" way - but I don't say that all compilers will manage to do this right without doing something different - and there's a high probability that printf itself uses the same piece of memory too, so there's no guarantee that either 15 or 42 is being printed, actually.Quote:
Originally Posted by Salem
Edit: To prove the point:
Three different results for the same code, depending on which compiler option. Another compiler will probably give another set of answers (at least on the second variant). The compiler is gcc-mingw 3.4.2Code:D:\temp>gcc -Wall ub.c
D:\temp>a
42, 42
D:\temp>gcc -Wall -O2 ub.c
D:\temp>a
16384, 16384
D:\temp>gcc -Wall -O3 ub.c
D:\temp>a
15, 42
--
Mats