Reference to a variable that goes out of scope
-
int *pi;
{
int i = 3;
pi = &i;
}
std::cout << *pi << std::endl;I figure that the *pi value in std:cout can not be trusted since i goes out of scope and the address of i can be used for other stuff. Is that correct? Thank
-
int *pi;
{
int i = 3;
pi = &i;
}
std::cout << *pi << std::endl;I figure that the *pi value in std:cout can not be trusted since i goes out of scope and the address of i can be used for other stuff. Is that correct? Thank
It depends on stack usage. If you return a local var thats now out of scope to a func that eats the stack it will get munged. If not, it is still there, but its is risky of course. Actually we found a windows bug that did just this. It returned a local var. This was OK till we hooked the func, and thus increased its tack usage. In your case i is out of scope at code level, but is still on the stack since you havent returned from your func yet (your code is actually compiled with i on the stack just after pi). --edit-- I see no one has responded. I guess an understanding of assembler (ie, the way code actually compiles) is totally foreign territory to todays 3G coders.
============================== Nothing to say.
-
It depends on stack usage. If you return a local var thats now out of scope to a func that eats the stack it will get munged. If not, it is still there, but its is risky of course. Actually we found a windows bug that did just this. It returned a local var. This was OK till we hooked the func, and thus increased its tack usage. In your case i is out of scope at code level, but is still on the stack since you havent returned from your func yet (your code is actually compiled with i on the stack just after pi). --edit-- I see no one has responded. I guess an understanding of assembler (ie, the way code actually compiles) is totally foreign territory to todays 3G coders.
============================== Nothing to say.
Erudite_Eric wrote:
It depends on stack usage.
AFAIK it doesn't so much depend on stack, but on the runtime libraries used: if they choose to invalidate a memory address as soon as it goes out of scope, then code like this will crash with an access violation. It may depend on compiler settings, but I've never seen code like that actually work on Windows XP or 7. Then again I never deliberately tried ;)
-
Erudite_Eric wrote:
It depends on stack usage.
AFAIK it doesn't so much depend on stack, but on the runtime libraries used: if they choose to invalidate a memory address as soon as it goes out of scope, then code like this will crash with an access violation. It may depend on compiler settings, but I've never seen code like that actually work on Windows XP or 7. Then again I never deliberately tried ;)
No, it isnt to do with libraries, but the very way local variables are allocated, ie, on the stack. This is only unwound, upwards dont forget, when the func the variables are declared in returns. Thats when the memory can be reused, by calling another func that declares its own variables. So if you look at assembler you will see stuff like ebp+4 being set to a value. This is a local variable. At the end you see a ret 4. This returns from the func and winds the stack back by the same number as the size of the local variables declared.
============================== Nothing to say.