0

http://cslibrary.stanford.edu/102/PointersAndMemory.pdf Reading this told us that when function gets called its locals gets called and when it exits its locals gets destroyed so that we can't use its locals in any of other function or out of that scope and they gave the example:

// TAB -- The Ampersand Bug function
// Returns a pointer to an int
int* TAB()
{
    int temp;
    return(&temp); // return a pointer to the local int
}

void Victim()
{
    int* ptr;
    ptr = TAB();
    *ptr = 42; // Runtime error! The pointee was local to TAB
}

but its working fine in the compiler while it shouldn't point which i can't understand is that how dereffrenced is working without even making it reference to the pointee. As function exits we can't use the locals

0

I don't really understand your question, because your English is a little bad, but I'll try to explain what the program does, and why the compiler will not compile this program.

Take a look at the following code (I added the main function so that we can compile and possible run the program).

faulty.c

#include <stdio.h>

// TAB -- The Ampersand Bug function
// Returns a pointer to an int
int* TAB()
{
    int temp;
    return(&temp); // return a pointer to the local int
}

void Victim()
{
    int* ptr;
    ptr = TAB();
    *ptr = 42; // Runtime error! The pointee was local to TAB
    printf("%d\n", *ptr);
}

int main(void)
{
    Victim();
    return 0;
}
  1. First the main function calls Victim.
  2. Then Victim creates a pointer to an int.
  3. Then it assigns to this pointer, the pointer returned by TAB.
  4. TAB creates an int, and the returns the pointer pointing to this int.

But by the time TAB returns, the int temp is out of scope, because it was local to TAB, so when you will try to access it from Victim, it doesn't exist in your stack, which means you can't access it. And if the compiler didn't stop you from doing that, you might get a runtime error, if you are in a big project, but in a small program like this, you could get away with it and your program will run, but you can never be sure it will have the correct output.

If you compile it using

clang -ggdb3 -O0 -std=c99 -Wall -Werror faulty.c -o faulty

it will not even compile, as it treats all warnings as errors. It shows

faulty.c:6:13: error: address of stack memory associated with local variable 'temp' returned [-Werror,-Wreturn-stack-address]
    return(&temp); // return a pointer to the local int
            ^~~~
1 error generated.

But if you use

clang -ggdb3 -O0 -std=c99 faulty.c -o faulty

it will give you a warning, but will still compile. It shows

faulty.c:8:13: warning: address of stack memory associated with local variable 'temp' returned [-Wreturn-stack-address]
    return(&temp); // return a pointer to the local int
            ^~~~
1 warning generated.

and if you execute it you might get

jharvard@ubuntu (~): ./faulty
42

If you run it, you might see the 42, but you can't be sure it will print the same next time you run it.

What you should take from that is that you should always treat warnings as errors, and you should never use code that produces warnings at compilation time, as you can't predict their behavior.

If this answers your question please accept it by clicking the gray check-mark to the left, so that it becomes green. You can also vote it up by pressing the up arrow above the check-mark.

3
  • well it pretty explains right, but my real question is what's the backend process going on which makes it goes wrong on the next time? how's the stack of operators working there – Habib ur Rehman Aug 24 '15 at 1:50
  • Do you mean how does the stacking of variables and functions work? And why the get out of scope once their context has finished? – ChrisG Aug 24 '15 at 7:01
  • yea i don't know whats the process, mean in this case variable gets referred after even exiting of the function. – Habib ur Rehman Aug 24 '15 at 11:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .