Thread: is there a runtime error here?

Originally Posted by rnx40401

I agree that getting abc back would be harder in a big system but in which case do we get a runtime error? when the memory is freed or when the memory is overwritten. My guess is that when the memory is overwritten we get some garbage back and no runtime error.

As a c++ programmer you should just not do it end of story.

For the curious here's why this rule was made into C++:
Local variables are declared in a series of values in concurrent memory called the stack. When a function is called or a block is started space is delegated at the end of the stack for its local variables and the constructors are called. When a function returns or a block ends, the destructors of those variables are called. Then those variables are then deemed not part of the stack. The data is still there in most cases -- why bother clearing unused data.

As such, any pointers or references to local variables are invalidated by the function return. However they will continue to work until another function is called or a local variable is declared*. When this happens the local variable(s) get declared at the end of the stack where the old local variables from the previous were. The old data is ignored completely.

*Or possibly when the next block starts. I don't know what's convention when writing compilers. Some compilers may do it one way others another.

This structure applies to just about all modern machines, big or small. Even embedded systems use it.

Yes, and the term "undefined behaviour" is just that - it is undefined. There are NO guarantees other than "it will most likely not always do exactly what you want". It may SOMETIMES (predictable if you understand what is going on in this particular compiler and environment). And changing the code ever so slightly can change the whole behaviour. Changing compiler flags, adding a function call, changing the usage of variables in your function, etc, etc.

The exact behaviour when something "undefined behaviour" happens is also undefined. The two most likely scenarios are "nothing" happens and "a crash". Runtime error is possible, but unlikely. It could start printing the screen to your local printer, it could create a black hole and suck all the data in the system into it.

Like King Mir says, the stack is where local variables are stored. They are generally not cleared when the called function is returning.

Freed memory is no longer "in use", but some other function may at any time use it later on.

Changing your code from

Code:

string &a = func();
cout << a;

to

Code:

string &a = func();
func2();
cout << a;

could easily break a function depending on data stored on the unused stack.

All of this gets even better if you use local variables after return in kernel mode, because every now and again, the processor will take an interrupt (keyboard, mouse, hard-disk, network, etc). The interrupt call will write data to the stack. So, say, 99 times out of 100, the returning of a local pointer is fine, but 1 time out of 100 it goes wrong - completely randomly!

--
Mats