If variables within a method are temporary. Then why can we access them C++?

Question

Hello;
I have a question concerning a small problem I am facing.
If the variables within a function are temporary. for example:

int* simpleCopy(int *newvalue)
{
   int result;
   int* pointerToResult;
   result = *newvalue;
   pointerToResult = &result;
   return pointerToResult;
}

If we try to use this function it will work. But I don't understand why.

from the compiler's perspective:

the function will create a variable named result and a pointer that point to this variable. and then will return the pointer. But when the function finishes and return the pointer the variable should be already gone yet It works and gives me accurate result. Could anyone explain the reason to me please.
Thanks in previos

_If we try to use this function it will work._ It only seems so. Nevertheless, it's [Undefined Behavior](https://stackoverflow.com/a/4105123/1505939). The address returned by `simpleCopy()` may not be used for access of contents. — Scheff's Cat, Mar 24 '20 at 12:12
FYI: [What is a dangling pointer](https://stackoverflow.com/a/17997314/7478597) or this one: [Can a local variable's memory be accessed outside its scope?](https://stackoverflow.com/a/6445794/7478597) — Scheff's Cat, Mar 24 '20 at 12:13
You've made a mistake. Someone has told you that the above code is an error. This is true. Now you have thought something like `this code is an error so it shouldn't work`. That's your mistake. Sometimes code with errors works anyway. The technical term for this is *undefined behaviour*. Code with errors generally has undefined behaviour. There's nothing in the C++ language that says bad code must fail. — john, Mar 24 '20 at 12:32
Analogy: If you know where somebody lives and that person dies, their house does not vanish and you might still be able to enter the house and poke at their remains. That doesn't mean that the person exists in the regular sense. — molbdnilo, Mar 24 '20 at 12:37

eerorika · Accepted Answer · 2020-03-24T12:17:09.763

Could anyone explain the reason to me please.

From the language's perspective: The behaviour of the program is undefined if you attempt to access the object outside of its lifetime.

A hypothetical compiler's perspective: You indirect through a pointer. The compiler generally doesn't know where it points to. It just generates instructions to read the value. That piece of memory may or might not contain the same bits that it did back when there was an object there. The memory might have been used for something else, or maybe not. Maybe the memory contains some special trap representation that causes the CPU to interrupt and raise a signal.

score 0 · Answer 2 · answered Mar 24 '20 at 12:22

The fact that this is UB is the right response. People will fight pretty strongly about this. Even say that your not allowed to say anything else than "it's UB"

But it's not a very useful answer. The reason why it 'wotks' is that your implementation uses a stack. When you called into simpleCopy it pushed some extra memory, including space for result. When you returned, the stack was popped but the memory remain untouched.

Since you didn't call other functions (until you do, in fact), the result remained there. But you should definitely not rely on this.

The reason is that optimizing compilers perform an insane amount of code modification. And they do it assuming you won't try to access variables that went out of scope.

If variables within a method are temporary. Then why can we access them C++?

2 Answers2