local stack variables

This is a discussion on local stack variables within the C++ Programming forums, part of the General Programming Boards category; Is there a program to test if your local stack variables are zeroed out after exiting a function? If so, ...

  1. #1
    UpTooLate
    Join Date
    Feb 2008
    Location
    New York
    Posts
    32

    Question local stack variables

    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?

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    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.

  3. #3
    UpTooLate
    Join Date
    Feb 2008
    Location
    New York
    Posts
    32
    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?

  4. #4
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    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.

  5. #5
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,621
    A better question would be: why must you do this?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  7. #7
    UpTooLate
    Join Date
    Feb 2008
    Location
    New York
    Posts
    32
    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.

  8. #8
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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

  9. #9
    The larch
    Join Date
    May 2006
    Posts
    3,573
    But they aren't?

    Code:
    #include <iostream>
    
    using namespace std;
    
    int* foo()
    {
        int n = 42;
        return &n; //undefined behaviour
    };
    
    int main()
    {
        int* p = foo();
        std::cout << *p;
    }
    This is undefined behaviour, since you shouldn't return pointers to local variables, but when I print it I see 42 (not 0).

    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.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  10. #10
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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?

  11. #11
    Registered User
    Join Date
    May 2008
    Location
    Paris
    Posts
    248
    This is undefined behaviour, since you shouldn't return pointers to local variables, but when I print it I see 42 (not 0).
    Can this be due to compiling with debugger info? I know that this changes the initialisation of variables.

  12. #12
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    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.

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,621
    Quote Originally Posted by master5001 View Post
    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?
    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).

    Quote Originally Posted by MarkZWEERS View Post
    Can this be due to compiling with debugger info? I know that this changes the initialisation of variables.
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I assure you it is expensive enough that your operating system does not do it.

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,621
    Really?
    Try this code (in debug mode, of course):

    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";
    }
    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:

    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 08:32 AM
  2. Finished Stack
    By the pooper in forum C Programming
    Replies: 11
    Last Post: 02-02-2005, 09:52 AM
  3. Stacks
    By Cmuppet in forum C Programming
    Replies: 19
    Last Post: 10-13-2004, 02:32 PM
  4. HEap and stack, I'm confused
    By indigo0086 in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 10-31-2002, 09:59 AM
  5. global and local variables
    By Unregistered in forum C++ Programming
    Replies: 2
    Last Post: 10-02-2001, 01:17 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21