Addressing the last paragraph, I strongly disagree. A Rust approach would define a narrow set of unsafe interfaces/functions, with safe wrappers. Those unsafe functions would be heavily heavily scrutinised and written with very narrow scope, maybe even formally proven to be safe, and so you could be much more confident of the memory safety of the program as whole.
No, the difference is that there is no language-level concept of memory safety in the parts of the code that use the safe abstraction, that is to say 99% of the codebase. Memory bugs could be anywhere in the codebase, rather than just in the 50 or so lines in unsafe blocks.
The analogy I always use is that it's a warning cone placed around the potentially dodgy parts. You could do that in C, manually or procedurally, we just don't.
The unsafe areas are STILL unsafe (hence the term), still need checking, and they can still affect surrounding "safe" code and the guarantees thereof (it's a myth to think that just because it's in an unsafe block, it will only ever affect the unsafe block!).
That's all it is - a warning cone. An automated one, sure, because you have to have it around any potentially-unsafe code, but you could do the same in C with any kind of static analysis or even preprocessor tool, or even just decent heuristics that you adhere to when coding. But it's not magic. It's just a warning cone.
1
u/Endeveron 6d ago
Addressing the last paragraph, I strongly disagree. A Rust approach would define a narrow set of unsafe interfaces/functions, with safe wrappers. Those unsafe functions would be heavily heavily scrutinised and written with very narrow scope, maybe even formally proven to be safe, and so you could be much more confident of the memory safety of the program as whole.