Comment by tptacek
2 days ago
Once again, people are grappling with an axiomatic definition of "memory safety" and avoiding the fact that it's a term of art with a very specific meaning: comprehensive protection from The Memory Corruption Vulnerabilities, which include overflows, the lifecycle vulnerabilities like UAF and type confusion, and uninitialized variables.
To the extent Fil-C and Rust both address these vulnerabilities, and don't include design features that in any practical way admit them, they're memory safe. What always feels like is missing from these kinds of analyses is that there are lots of memory-safe programming environments. Almost every Java, Python, Ruby, Javascript, and Go program is memory safe, in the real meaning of the term.
The competition to lock in and promote adoption of the "most" memory-safe language is a category error... unless you do what every language-war argument does, and redefine the term.
The really silly thing is that Fil-C and Zig here have chosen a definition of memory safety that specifically excludes a bunch of overflow vulnerabilities and type confusion. At least it’s been specifically defined, but such a narrow definition makes the end result to me almost wholly uninteresting. UAF no longer turns into a RCE, but your average parsing packet code is still just as likely to be a buggy mess.
Even within Rust some folks do this to themselves, misusing unsafe with code that is 100% safe Rust, only to taint code that should only be called in specific cases, completely unrelated to memory safety.
I never seen this happen with GC/RC languages that also support unsafe code blocks.