5 ms·

This article comes up with yet another definition of memory safety. Thankfully, it does not conflate thread safety with memory safety. But it does a thing that

This article comes up with yet another definition of memory safety. Thankfully, it does not conflate thread safety with memory safety. But it does a thing that makes is both inaccurate (I think) and also not helpful for having a good discussion: TFA hints at memory safety requiring static checking, in the sense that it's written in a way that would satisfy folks who think that way, by saying thingys like "never occur" and including null pointer safety. Is it necessary for the checking to be static? No. I think reasonable folks would agree that Java is memory safe, yet it does so much dynamic checking (null and bounds). Even Rust does dynamic checking (for bounds). But even setting that aside, I don't like how the way that the definition is written in TFA doesn't even make it unambiguous if the author thinks it should be static or dynamic, so it's hard to debate with what they're saying. EDIT: The definition in TFA has another problem: it enumerates things that should not happen from a language standpoint, but I don't think that definition is adequate for avoiding weird execution. For example, it says nothing about bad casts, or misuses of esoteric language features (like misusing longjmp). We need a better definition of memory safety.

tptacek 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. I don't see where you're seeing the article drawing a line between static and dynamic defenses. The article opens by noticing Rust isn't the first memory safe language. It is by implication referring to things like Java, which have dynamic, runtime-based protections against memory corruption.
- deleted 1y ago
  [deleted]
- 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 ago
    From 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.
bgwalter 1y ago
TFA is too long, like all articles since the arrival of you know what. So the definitions are scattered. Here it claims: Rust's big step function was to offer memory safety at compile time through the use of static analysis borrowed and grown out of prior efforts such as Cyclone, a research programming language formulated as a safe subset of C. In other words, Rust has solved the halting problem since the static checking of array bounds is undecidable in the general case!
- Jtsummers 1y ago
  > In other words, Rust has solved the halting problem No one is making that claim.
  - bgwalter 1y ago
    "offer memory safety at compile time through the use of static analysis" For arrays, this problem is not computable at compile time, hence the sarcastic remark that, IF THE ABOVE DEFINITION IS TAKEN AT FACE VALUE, Rust must have solved the halting problem. Downvoters are so dumb here.
    - deleted 1y ago
      [deleted]
    - Jtsummers 1y ago
      > IF THE ABOVE DEFINITION IS TAKEN AT FACE VALUE Why are you shouting? That's what twits do. You don't want to be a twit, do you? Read the site guidelines, emphasis is done with italicized text marked up with an * at the beginning and another * at the end. But to respond to the topic at hand: Are you familiar with the distinction between sound (what Rust aims for) and complete analyses?
      - bgwalter 1y ago
        Are you familiar with the fact that Rust does array bounds checking at runtime, contrary to the cited claim? And that this was kind of the topic of this subthread? https://stackoverflow.com/questions/28389371/why-does-rust-check-array-bounds-at-runtime-when-most-other-checks-occur-at-c https://stackoverflow.com/questions/28389371/why-does-rust-c...
creatonez 1y ago
Are you responding to an AI hallucinated version of this article? It doesn't say what you're saying it does.

tptacek 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. I don't see where you're seeing the article drawing a line between static and dynamic defenses. The article opens by noticing Rust isn't the first memory safe language. It is by implication referring to things like Java, which have dynamic, runtime-based protections against memory corruption.

deleted 1y ago
[deleted]
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 ago
  From 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.

bgwalter 1y ago

TFA is too long, like all articles since the arrival of you know what. So the definitions are scattered. Here it claims: Rust's big step function was to offer memory safety at compile time through the use of static analysis borrowed and grown out of prior efforts such as Cyclone, a research programming language formulated as a safe subset of C. In other words, Rust has solved the halting problem since the static checking of array bounds is undecidable in the general case!

Jtsummers 1y ago
> In other words, Rust has solved the halting problem No one is making that claim.
- bgwalter 1y ago
  "offer memory safety at compile time through the use of static analysis" For arrays, this problem is not computable at compile time, hence the sarcastic remark that, IF THE ABOVE DEFINITION IS TAKEN AT FACE VALUE, Rust must have solved the halting problem. Downvoters are so dumb here.
  - deleted 1y ago
    [deleted]
  - Jtsummers 1y ago
    > IF THE ABOVE DEFINITION IS TAKEN AT FACE VALUE Why are you shouting? That's what twits do. You don't want to be a twit, do you? Read the site guidelines, emphasis is done with italicized text marked up with an * at the beginning and another * at the end. But to respond to the topic at hand: Are you familiar with the distinction between sound (what Rust aims for) and complete analyses?
    - bgwalter 1y ago
      Are you familiar with the fact that Rust does array bounds checking at runtime, contrary to the cited claim? And that this was kind of the topic of this subthread? https://stackoverflow.com/questions/28389371/why-does-rust-check-array-bounds-at-runtime-when-most-other-checks-occur-at-c https://stackoverflow.com/questions/28389371/why-does-rust-c...

creatonez 1y ago

Are you responding to an AI hallucinated version of this article? It doesn't say what you're saying it does.