2 ms·

You are committing the exact generalization of segfaults=bad that I mentioned in the parent comment. Memory safety violations which cause segfaults can often b

You are committing the exact generalization of segfaults=bad that I mentioned in the parent comment. Memory safety violations which cause segfaults can often be turned into an actual exploit. That does not mean the same thing as, "If A is a segfault, A can be turned into an exploit." And it's not better to "explicitly" abort, because you get zero benefit from that. And because testing for null would be slow. (This is why JVM implementations often let it segfault.)

steveklabnik 10y ago
I didn't say that all segfaults are always security problems, just that the often are. I think we'll have to agree to disagree here, though. Segfaults are memory safety problems, and unwrap is significantly different because it's not a memory safety problem.
- SamReidHughes 10y ago
  You can "agree to disagree" about a definition, but we'll also have to agree to disagree on what properties the definition should have. I'd say that language L is memory-safe, then a language M which is like L, except that some programs terminate earlier, should also be memory-safe. We'll have to "agree to disagree" about that. I'd say a compiler's choice of behavior-maintaining implementation technique should not determine whether a language is memory-safe. We'll have to "agree to disagree" about that. I'd say a definition of memory safety should correspond to some mutually relevant notions of being safe (with consequences around security and ease of debuggability), and that it shouldn't include some kinds of unrelated notions about termination safety while omitting other kinds of termination safety. We'll have to "agree to disagree" about that. > I didn't say that all segfaults are always security problems, just that the often are. My mistake, I assumed you were trying to make a point that had some bearing on the discussion.

steveklabnik 10y ago

I didn't say that all segfaults are always security problems, just that the often are. I think we'll have to agree to disagree here, though. Segfaults are memory safety problems, and unwrap is significantly different because it's not a memory safety problem.

SamReidHughes 10y ago
You can "agree to disagree" about a definition, but we'll also have to agree to disagree on what properties the definition should have. I'd say that language L is memory-safe, then a language M which is like L, except that some programs terminate earlier, should also be memory-safe. We'll have to "agree to disagree" about that. I'd say a compiler's choice of behavior-maintaining implementation technique should not determine whether a language is memory-safe. We'll have to "agree to disagree" about that. I'd say a definition of memory safety should correspond to some mutually relevant notions of being safe (with consequences around security and ease of debuggability), and that it shouldn't include some kinds of unrelated notions about termination safety while omitting other kinds of termination safety. We'll have to "agree to disagree" about that. > I didn't say that all segfaults are always security problems, just that the often are. My mistake, I assumed you were trying to make a point that had some bearing on the discussion.