Practical Memory Safety
10 points by raymii
10 points by raymii
While an imprecise definition of memory safety can be useful, I think this one doesn't quite hit the spot: A language can have complicated rules for what causes allocations and when and how memory gets freed, making it hard to e.g. predict how much memory a program will be using, but still be memory safe (especially if the language doesn't concern itself much with memory).
Nevertheless I think it's more useful than the one given by Filip Pizlo at SSW this year, according to which C (as typically implemented targeting a computer with a MMU) is memory-safe: "In a memory safe programming language, memory logic bugs don't give the attacker control over all memory."
complicated rules for what causes allocations and when and how memory gets freed
That’s an interesting example! I haven’t really considered these as “rules” in the way, which I guess is because I was thinking more about rules that are checked (or not checked) either at runtime or at compile time.
But I’m not sure if I’ll say it’s “unsafe” - eg Python with the GC disabled is memory safe - just not very efficient.
If it doesn't enable capability-safety, it probably isn't true memory-safety.
Rust people are always trying to define memory safety such that it includes only Rust and excludes their main competition. I'm gonna do the same until we can all agree to discuss it honestly. Come on, people. Be reasonable.