Why returning a pointer pointed to the local memory doesn't collapse?

Question

Possible Duplicate:
Can a local variable's memory be accessed outside its scope?

I thought the following call to f() will get a pointer to a local memory that will not be handled by the compiler (which is dangerous according to the textbook). However, it still works well. Not sure whether this is safe or not.

#include <iostream>

using namespace std;

int * f()
{
   int  v[1000000];
   for (int i=0; i<1000000; i++) v[i]=i;
   cout<<v[7]<<endl;
  return  v;
}

int main()
{
   int * v = f();
   cout<<v[7]<<endl;
   return 0;
}

score 4 · Answer 1 · answered Apr 27 '12 at 15:31

4

The pointer v in main() is a dangling pointer after f() returns. Dereferencing a dangling pointer is undefined behaviour, meaning anything can happen:

it could crash
it could print an incorrect integer value
it could print the correct integer value

answered Apr 27 '12 at 15:31

hmjd

120,187
20
207
252

score 4 · Answer 2 · answered Apr 27 '12 at 15:31

Because it is Undefined Behavior and an Undefined Behavior does not necessary mean a crash.
It is unsafe ofcourse.
An Undefined Behavior means that all safe bets are off and literally anything might happen, So if it does not crash does not mean it is valid. It is invalid and you should just not do it!

thb · Accepted Answer · 2012-04-27T15:42:40.943

Interesting question. Your code is likely to work (or seem to work) on some platforms and to fail on others.

The reason your code seems to work is that the memory the function f() reserves on the stack is released but not erased when f() returns. Being released, the memory becomes available for other functions to use; but it might not be overwritten until another function actually does use it.

Some others here are correctly pointing out that your code evokes undefined behavior, and technically that is true. However, there is a reason you are getting the particular undefined behavior you are getting, and that is what my answer is about.

On some platforms, including the x86, after f() releases the memory of v[], the first memory to be reused will normally be the memory that used to hold v[999999]. It may be a long time before the memory that holds v[0] gets reused. Hence, the data from v[7] is spuriously still present.

There is at least one more wrinkle. Some implementations, using some settings, may overwrite all released memory immediately with random data, to guard against security risks. (What if v[] held a password, for example? The random data would wipe it safely away.)

score 1 · Answer 4 · answered Apr 27 '12 at 15:34

1

Undefined behavior: it can work, or crash, or erase your hard drive, or implode into a black hole, or run off with your wife.

One thing's for sure, though: it will cause you to fail your class.

answered Apr 27 '12 at 15:34

Matt

10,434
1
36
45

Maybe rename the function 'f' to 'demo_undefined_behavior' and get an A? – Art Swri Apr 27 '12 at 15:48

score 1 · Answer 5 · answered Apr 27 '12 at 15:40

As noted in other answers, it's undefined behavior so you cannot depend on it working correctly. It may work ok on some platforms or with some compilers but not others. You are 'getting away with it' mostly because your program is small and simple. The more you elaborate the program, the more likely you'll run into problems.

Why returning a pointer pointed to the local memory doesn't collapse?

5 Answers5