Is there a program to test if your local stack variables are zeroed out after exiting a function? If so, how can I go about doing this?
Is there a program to test if your local stack variables are zeroed out after exiting a function? If so, how can I go about doing this?
Your local stack variables don't exist after the function. (Assuming you mean variables local to the function.)
If you want that piece of memory to read 0, you would have to set it as such before the function ends (and I would guess that your compiler may well optimize it away).
If you mean something else, you'll have to be more specific.
I think you answered my question.
I need to write a program to check if C++ zeroes out the local stack variables after a function. I could do this simply by writing a class function variable 'x' and writing a main variable 'x' and writing a different definition for the variable in the function than in main. I would then ask my program to output 'x' at the end of the program and it should output main's variable 'x', correct?
It would output main's variable x, yes. On the other hand, that doesn't have anything to do with "zero[ing] out the local stack variables after a function". (This is just checking that myfunc's x and main's x are not the same, not that myfunc's x is zero after the function ends.)
Presumably you would need to return a dangling pointer from the function (Very Bad in the normal scheme of things, but since you're trying to get at implementation details, I guess we'll let it go this time) to a local variable and dereference that pointer after the function ends, if you wanted to see what actually happened to the memory.
This sounds like a job for Segment Fault Man! Or if enough time lapses you may get to deal with his loveable sidekick The Access Violator. If you really deemed it necessary you could zero out the entire function. But man is that going to be a nasty block of code. I will take no part in helping you write useless code.
Oh god, I must do this for my MIPS assembly class. We are trying to prove that local variables are actually zero'd out after exiting a function (in C++) and I haven't done any C++ code since last semester and even then we barely covered pointers. This will be a lot of fun.
Yeah I figured you were an assembly language programmer. Your questions seem to stem from someone who is more used to assembler languages. Good ol' MIPS
But they aren't?
This is undefined behaviour, since you shouldn't return pointers to local variables, but when I print it I see 42 (not 0).Code:#include <iostream> using namespace std; int* foo() { int n = 42; return &n; //undefined behaviour }; int main() { int* p = foo(); std::cout << *p; }
Also, if they were zero'd out after leaving a function, shouldn't they also be zero when entering a function (alas, uninitialized variables don't contain 0)?
Or, if you know assembly, wouldn't you be able to check the output of the compiler to see if there are any instructions to zero out anything when leaving a function (I don't)?
Last edited by anon; 10-06-2008 at 03:59 PM.
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
I believe the purpose of the assignment is to prove that fact, anon. Now that I am a little more familiar with why he is asking that I am comfortable to know he isn't just keeping dangling pointers for later use. Its just a computer science proof.
Zeroing out memory is expensive Amyaayaa. Could you even begin to imagine how much overhead it would cost to have every single stack zeroed prior to, or upon exiting each and every function called?
Can this be due to compiling with debugger info? I know that this changes the initialisation of variables.This is undefined behaviour, since you shouldn't return pointers to local variables, but when I print it I see 42 (not 0).
The stack isn't necessarily destroyed or overwritten immediately. Its just considered to have no promises attached to it. In essence, you are doing something that yields no consistent behavior.
It's not that expensive. One instruction at most and it might just as well end up in the cache if you're lucky (though I don't know if that can happen for sure).
Debuggers can initialize variables with known values. However, be default variables contain "junk", or in other words - undefined contents.
Point being, variables are not zeroed before creation nor after their destruction.
All that happens is pretty much that the ebp register (I think it's this one?) is changed (it's the stack pointer).
But regardless of all that - this changes from system to system and has no connection to C++. A variable's value before use is undefined and so is its contents after destruction.
I assure you it is expensive enough that your operating system does not do it.
Really?
Try this code (in debug mode, of course):
I fail to see a big speed hit, especially since results seem to yield a lot of time when the second (!) is faster than the first:Code:#include <windows.h> #include <iostream> using namespace std; int main() { DWORD dwTick1 = GetTickCount(); for (int i = 0; i < 1000000000; i++) int x; cout << "Took " << GetTickCount() - dwTick1 << " ms.\n"; dwTick1 = GetTickCount(); for (int i = 0; i < 1000000000; i++) int x = 0; cout << "Took " << GetTickCount() - dwTick1 << " ms.\n"; }
Took 4250 ms.
Took 4079 ms.
Took 3954 ms.
Took 3703 ms.
Took 3937 ms.
Took 3844 ms.
Can you tell how it's expensive?