I found this question on my study guide, and I am not sure why it would be bad to return a pointer to a local variable/parameter. Any ideas?
6 Answers
It's not so much a "bad practice" (implying that it might cause problems) as much as it is a practice that will absolutely cause undefined behavior. It's like dereferencing a null pointer: don't do it and expect your program to behave within the limits of logic.
Explanation:
When a local variable (including a parameter) is declared, it is given automatic storage, meaning that the compiler takes care of allocating memory for the variable and then deallocating that memory without any effort on the part of the programmer.
void foo(int bar)
{
int baz;
} //baz and bar dissappear here
When the variables' lifetime ends (such as when the function returns), the compiler fulfills its promise and all automatic variables that were local to the function are destroyed. This means that any pointers to those variables now point to garbage memory that the program considers "free" to do whatever it wants with.
When returning a value, this isn't a problem: the program finds a new place to put the value.
int foo(int bar)
{
int baz = 6;
return baz + bar; //baz + bar copied to new memory location outside of foo
} //baz and bar disapear
When you return a pointer, the value of pointer is copied as normal. However, the pointer still points to the same location which is now garbage:
int* foo(int bar)
{
int baz = 6;
baz += bar;
return &baz; //(&baz) copied to new memory location outside of foo
} //baz and bar disapear! &baz is now garbage memory!
Accessing this memory is undefined behavior, so your program will almost certainly misbehave in some way or another. For instance, I once fell victim to this exact problem, and while my program did not crash or terminate, my variables began degrading into garbage values as the compiler overwrote the "free" memory.

- 14,133
- 7
- 40
- 79
Once the function returns, the local variables and parameters, which were on the stack, have been de-allocated. They may still exist, but there are no guarantees, and when something decides to use the stack they'll certainly be whacked.
Using the diagram from WP:
The stack pointer up at the top is where new variables can be safely allocated and placed (such as when calling a function). When the function (e.g. DrawLine) returns though, they're taken off the stack (the stack pointer is just incremented so it no longer points at out-of-scope, Green, variables). Anything that comes along later and allocates and uses stack space will destroy the old values.

- 25,754
- 12
- 83
- 121
If you return a pointer to a local variable once the function returns it is out of scope. From then on it is undefined behavior if you access the returned pointer.

- 1,277
- 9
- 14
A local variable is stored on the Stack. Values stored on the stack are destroyed once the function / code block exits (ie., you reach the end of a function -- technically they can last longer, but that's another discussion). Therefore, the pointer (which points to an address in particular place in memory) points to a value which may no longer exist.

- 20,376
- 9
- 50
- 82
Because the address of that variable belongs to the stack frame from which it was created. Nothing else. Once you return
, that activation record gets cleaned up and anything that was there previously is now undefined.

- 5,552
- 1
- 18
- 18