Thread: Return a pointer to a variable declared inside the function (basic question)

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

Originally Posted by lecter55

** 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.

To prove the point that this DOESN'T work, we can do this:

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("&#37;d, %d", *number, *number2);
    return 0;
}

My guess, is that you will see 42 for both numbers, if it gets any predictable result at all.

Edit: Fixed up the code to match g() with f() - thanks to QuantumPete for pointing out the bug.

Originally Posted by matsp

My guess, is that you will see 42 for both numbers, if it gets any predictable result at all.

That's interesting, I get 15 and 42 printed out...

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

Originally Posted by gcc manual

-fno-defer-pop
Always pop the arguments to each function call as soon as that function returns. For machines which must pop arguments after a function call, the compiler normally lets arguments accumulate on the stack for several function calls and pops them all at once.

Disabled at levels -O, -O2, -O3, -Os.

If defer-pop is enabled, then your variable, which has gone out of scope, can last a bit longer than you might otherwise suspect.

Just goes to show you that it's impossible to get a consistent answer out of UB

Originally Posted by Salem

> 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.

Just goes to show you that it's impossible to get a consistent answer out of UB

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.

Edit: To prove the point:

Code:

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

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.2
--
Mats