0
#include <stdlib.h>
#include <stdio.h>


int* test()
{
    int *p;
    if (1)
    {
        int y = 10;
        p = &y;     
    }
    printf("Address = %p\n", p);
    printf("Value = %d\n", *p);
    return p;
}

int main()
{
    int *ptr = test();
    printf("Adress on main = %p\n", ptr);
    *ptr = 15;
    printf("Value on main = %d\n", *ptr);
}

I thought here "y" will be deleted when the "if" scope or "test" function ends and when I try to access to its address I'm gonna get Segmentation Fault but everything was okay and I was even able to change the value in the pointer on main function how is this possible. Why memory of "y" is not deleted. The output was:

Address = 0x7ffe7e84432c
Value = 10
Adress on main = 0x7ffe7e84432c
Value on main = 15
Ermand
  • 23
  • 4
  • 4
    Undefined behaviour is undefined. Anything can happen, you cannot access a variable after its lifetime ends through any means - may it be a pointer, or reference. – Quimby Jul 26 '22 at 06:26
  • 1
    The life-time of a variable ends when the scope of its definition ends. In the case of `y` and `p`, the pointer `p` to `y` will become immediately invalid. Attempting to dereference the pointer will lead to *undefined behavior*. – Some programmer dude Jul 26 '22 at 06:27
  • `y`'s scope is indeed till the end of the `if`. Accessing it afterwards (via an address you keep) is undefined behavior (UB). It doesn't mean it's guaranteed to crash. – wohlstad Jul 26 '22 at 06:27
  • 2
    You think that C++ is checking for the mistakes in your code. That's a reasonable thing to think, but it is not true. Instead when you write code like the above example, all C++ says is that the behaviour of your program is **undefined**, it's does not say that it must crash. – john Jul 26 '22 at 06:30
  • 1
    Some compilers allow you to check for those problems, at the cost of some performance. Look up "sanitizers". – HolyBlackCat Jul 26 '22 at 06:37
  • 1
    fwiw, you do not need `if(1)`. A pair of brackets is sufficient to start and end a scope – 463035818_is_not_an_ai Jul 26 '22 at 06:39
  • or look at this https://godbolt.org/z/9qjsPcWex to see how your compiler can help to spot such issues – 463035818_is_not_an_ai Jul 26 '22 at 06:40
  • Rule of thumb: Don't assume that C or C++ does any validity tests. Tests take time and that time would be wasted if the program didn't have logic errors that required checking. In order to get the best possible efficiency, C and C++ generally assume that your code is correct. – user4581301 Jul 26 '22 at 06:45
  • *"I thought [...] I'm gonna get Segmentation Fault"* -- this is usually an incorrect conclusion. There is never a requirement for a segmentation fault to occur. There are some things that are likely to cause a seg fault, but the only ones I would rely on to any extent are assigning to and reading from the result of de-referencing a null pointer. And even that can be optimized away sometimes. Especially if I am trying to demonstrate what a seg fault looks like. Thanks Murphy. – JaMiT Jul 26 '22 at 07:27
  • Objects on the stack are **never** deleted. The term you're looking for is **destroyed**. Objects with automatic lifetime (i.e., objects on the stack) get destroyed when they go out of scope. – Pete Becker Jul 27 '22 at 03:47

0 Answers0