3 ms·
> I want to be there with you, but the definition this piece uses is, I think, objectively the correct one --- "memory safety", at least as used in things like
by pizlonator 1y ago
> I want to be there with you, but the definition this piece uses is, I think, objectively the correct one --- "memory safety", at least as used in things like "The Case For Memory Safe Roadmaps" government guidance, is simply the property of not admitting to memory corruption vulnerabilities.
This piece does not define memory safety as "not admitting memory corruption vulnerabilities". If it was using that definition, then:
- You and I would be on the same page.
- I would have a different complaint, which is that now we have to define "memory corruption vulnerability". (Admittedly, that's maybe not too hard, but it does get a bit weird when you get into the details.)
The definition in TFA is quoted from Hicks, and it enumerates a set of things that should never happen. It's not defining memory safety the way you want.
- tptacek 1y agoFrom this, I think we probably just mostly read the piece differently, and you probably read it more carefully than I did. (I know your background in this space). I'm always a little guarded about message board definitions of "memory safety", because they tend to be axiomatically derived from the words "memory" and "safety", and they tend to have an objective of saying that there's only one mainstream language that provides memory safety.
- pizlonator 1y ago> and they tend to have an objective of saying that there's only one mainstream language that provides memory safety. Yeah! I agree it's hard to do it without some kind of axioms or circularity, but it's also important to get the definition right, because at some point, we'll need to be able to objectively say whether some piece of critical software is memory safe, or not. So we have to keep trying to find a good definition. I think that means rejecting the bad definitions.