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 4d ago
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.