I could be wrong, but I think this is dangling, but you're getting lucky - likely because your program doesn't do anything else. This is still undefined behavior. When i goes out of scope, the compiler is free to reuse that memory location for anything else. However, p is still pointing to the same location. If nothing else has happened to that memory, it's still sitting there unchanged, so your program produces the correct output, but there's nothing in the standard mandating this to be true anymore.
You can see this behavior sometimes when trying to print a variable that hasn't been initialized in your program. You might get something random back, which is just whatever that memory was previously used for. Even though the program that allocated it has called all its destructors and released it to the OS, that doesn't mean it's been overwritten yet, just that it's allowed to be reused if needed.
So, the same as I replied to someone on Twitter who had a pretty similar answer; and as you said by saying I'm "getting lucky": The compiler that SoloLearn was just being merciful in its decision not to provide a segfault?
A segfault always comes from the OS, not the compiler, when you hit memory that's "not yours". In this case, the compiler did what you asked, it showed you the memory at that location. I believe the other comment is correct about why this is reproducible, both i and p live in the stack frame allocated for main(), which still exists when the printing happens, so nothing has had a chance to interfere even though you're pointing to a variable that isn't in scope. The memory is still "yours", as in, belongs to the program, even though semantically within your program it's out of scope, so the OS doesn't complain. However, it's not guaranteed to be reproducible, and different compilers are free to handle this in totally different ways.
Sounds right to me. To add to it, I also am far from sure (C goes back some decades in terms of practical use and experience for me) but it could well be that i and p are both living on a stack, and that the embracing scope of the function main() in this instance remains on the stack until that function returns. Seen another way it may be undefined behaviour but also slightly better than mere chance that you experience it in this example (i.e. that it's reliably reproducible) in part because it's a a very terse example but also possibly because the anonymous scope you'd declared i in may (being anonymous) have the stack life that the enclosing function's scope does. That is assuming C puts variables on the stack at all .... my memory on implementation details is, alas, rather distant ;-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I could be wrong, but I think this is dangling, but you're getting lucky - likely because your program doesn't do anything else. This is still undefined behavior. When
igoes out of scope, the compiler is free to reuse that memory location for anything else. However,pis still pointing to the same location. If nothing else has happened to that memory, it's still sitting there unchanged, so your program produces the correct output, but there's nothing in the standard mandating this to be true anymore.You can see this behavior sometimes when trying to print a variable that hasn't been initialized in your program. You might get something random back, which is just whatever that memory was previously used for. Even though the program that allocated it has called all its destructors and released it to the OS, that doesn't mean it's been overwritten yet, just that it's allowed to be reused if needed.
So, the same as I replied to someone on Twitter who had a pretty similar answer; and as you said by saying I'm "getting lucky": The compiler that SoloLearn was just being merciful in its decision not to provide a segfault?
A segfault always comes from the OS, not the compiler, when you hit memory that's "not yours". In this case, the compiler did what you asked, it showed you the memory at that location. I believe the other comment is correct about why this is reproducible, both
iandplive in the stack frame allocated formain(), which still exists when the printing happens, so nothing has had a chance to interfere even though you're pointing to a variable that isn't in scope. The memory is still "yours", as in, belongs to the program, even though semantically within your program it's out of scope, so the OS doesn't complain. However, it's not guaranteed to be reproducible, and different compilers are free to handle this in totally different ways.Sounds right to me. To add to it, I also am far from sure (C goes back some decades in terms of practical use and experience for me) but it could well be that
iandpare both living on a stack, and that the embracing scope of the functionmain()in this instance remains on the stack until that function returns. Seen another way it may be undefined behaviour but also slightly better than mere chance that you experience it in this example (i.e. that it's reliably reproducible) in part because it's a a very terse example but also possibly because the anonymous scope you'd declarediin may (being anonymous) have the stack life that the enclosing function's scope does. That is assuming C puts variables on the stack at all .... my memory on implementation details is, alas, rather distant ;-)