Just jump to
This could be argued 2 ways:
1: You did access memory you should of not, but it was my memory, the guard, so I did prevent you from accessing an illegal memory location, therefore, no segfault
2: You claim that you prevent segfaults, that would mean that I won't be able to access an illegal memory location, therefore, I should not be able to go outside my own stack size but I did. I did access an illegal memory location to my application. Me hitting one of the guards doesn't mean I didn't access an illegal memory location. This can be achieved even with a C++ compiler flag but they do not claim that the language does not segfault. The conclusion: segfault
I incline towards the second argument. It is a segmentation fault, it was not prevented but the effect of it was amortized by guards. So, Rust is safe of memory corruption but not segfaults.
To make it more clear. Segfaults are not the dead bodies on the battlefield(the corruption of the memory, therefore the guards protected from it) but the people yelling on the hills, they might shed some blood, or they might not(A segfault is accessing an illegal memory location - guards are also illegal memory locations, though they are smartly placed to help prevent the blood from being shed).
Not sure the analogy helps , especially the second part.
I also understand your point. You think of it as if the guards are an extension of the application, therefore, you are accessing your own memory, just that you have some checks in there that make you crash.
But I incline to think of it as: [shadow memory placed by tools][Application][shadow memory]
The Application is the realm where the developer works in. If he hits the shadow memory, it is not what he intended to do, he didn't expect that, it is a segmentation fault.
What the developer thinks is irrelevant.
The claims are made about Rust the Application, not Rust the Developer.
It does not claim that it will make the developer write software
that runs blazingly fast, prevents segfaults, and guarantees thread safety. The Rust Application will accomplish these...
That it accomplishes these(except the
runs blazingly fast) by forcing most of the times the developer to write the correct code through the help of the type system, borrow checker... is another thing.
Now, if we think of the guards as an extension of the application, the same way we would think of the garbage collector as an extension of the application in managed programming languages, then this does prevent segmentation faults, the same way a garbage collector "prevents memory leaks".
The issue then would be that the panick Rust throws, is a misleading message that should actually say something like "Guard Page Exception - A page of memory that marks the end of a data structure, such as
a stack or an array, has been accessed."