I wrote a program in C having dangling pointer.
#include
int *func(void)
{
int num;
num = 100;
return #
}
int func1(void
Please study functions from basic C. Your concept is flawed...main
should be
int main(void)
{
int *a = func();
int b;
b = func1();
printf("%d\n%d",*a,func1());
return 0;
}
This will output 100 200
It's undefined behavior. It could work correctly on your computer right now, 20 minutes from now, might crash in an hour, etc. Once another object takes the same place on the stack as num
, you will be doomed!
With dangling pointers, the result of a program is undefined. It depends on how the stack and the registers are used. With different compilers, different compiler versions and different optimization settings, you'll get a different behavior.
Dangling pointers (pointers to locations that have been disassociated) induce undefined behavior, i.e. anything can happen.
In particular, the memory locations get reused by chance* in func1
. The result depends on the stack layout, compiler optimization, architecture, calling conventions and stack security mechanisms.
Returning a pointer to a local variable yields undefined behaviour, which means that anything the program does (anything at all) is valid. If you are getting the expected result, that's just dumb luck.
It's because of the way the memory gets allocated.
After calling func
and returning a dangling pointer, the part of the stack where num
was stored still has the value 100
(which is what you are seeing afterwards). We can reach that conclusion based on the observed behavior.
After the change, it looks like what happens is that the func1
call overwrites the memory location that a
points to with the result of the addition inside func1
(the stack space previously used for func
is reused now by func1
), so that's why you see 200.
Of course, all of this is undefined behavior so while this might be a good philosophical question, answering it doesn't really buy you anything.