Hacker News Reader

Comment by samdoesnothing | Hacker News Reader

> Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.

I don't really see how that's a) a scepticism of memory safety or b) how it's not seen as a reasonable position. Just because someone doesn't think X is the most important thing ever doesn't mean they are skeptical of it, but rather that the person holding the 100% viewpoint is probably the one with the extreme position.

View on HN

Look at the definition quoted in the article:

    [A] program execution is memory safe so long as a particular list of bad things, called memory-access errors, never occur

"95% memory safety" is not a meaningful concept under this definition! That's very much skepticism of memory safety as defined in this article, to highlight the key phrase in the comment you're quoting.

It's also not a meaningful concept within the C++ language standard written by the committee Herb Sutter chairs. Memory unsafety is undefined behavior (UB). C++ code containing UB has no defined semantics and is inherently incorrect, whether that's 1 violation or 1000.

Now, we can certainly discuss the practical ramifications of 95% vs 100%, but even here Herb's arguments have fallen notoriously flat. I'll link Sean Baxter's piece on why Herb's actual proposals fail to achieve even these more modest goals as an entry point [0]. No need to rehash the volumes of digital ink already spilled on this subject in this particular comment thread.

[0] https://www.circle-lang.org/draft-profiles.html

Skepticism of an absolutist binary take on memory safety is not the same as skepticism of memory safety in general and it's important to distinguish the two.

It's like saying that people skeptical of formal verification are actually skeptical of eliminating bugs. Most people are not skeptical of eliminating bugs, but they might be skeptical of extreme approaches to do so.

As I explained in a sibling comment, memory safety violations aren't comparable to logic bugs. Avoiding them isn't an absolutist take, it's just a basic requirement in common programming languages like C and C++. That's not debatable, it's written right into the language standards, core guidelines, and increasingly government standards too.

If you think that's impossibly difficult, you're starting to understand the basic problem. We already know from other languages that memory safety is possible. I've already linked one proposal to retrofit similar safety onto C++. The author of Fil-C is elsewhere in these comments arguing for another way.

Everything you say about memory safety issues applies to logic bugs too. And likewise in reverse - you can have a memory safety issue that doesn't result in a vulnerability or crash. So I don't buy it that memory safety is so different from other types of bugs that it should be considered a binary issue and not on a spectrum like everything else!

> Everything you say about memory safety issues applies to logic bugs too.

It doesn't, because logic bugs generally have, or can be made to have limited scope.

> And likewise in reverse - you can have a memory safety issue that doesn't result in a vulnerability or crash.

No you can't, not in standard C. Any case of memory unsafety is undefined behaviour, therefore a conforming implementation may implement it as a vulnerability and/or crash. (You can have a memory safety issue that happens to not result in a vulnerability or crash in the current version of gcc/clang, but that's a lot less reassuring)

This whole memory-bugs-are-magical thinking just comes from the Rust community and is not an axiomatic truth.

It’s also trivial to discount, since the classical evaluation of bugs is based on actual impact, not some nebulous notions of scope or what-may-happen.

In practice, the program will crash most of the time. Maybe it will corrupt or erase some files. Maybe it will crash the Windows kernel and cause 10 billion in damages; just like a Rust panic would, by the way.

We simply don't treat "gcc segfaults on my example.c" file the same way as "libssl has an exploitable buffer overflow". That's a synopsis of the nuance.

Materials to be consumed by engineers are often unsafe when misused. Not just programs like toolchains with undefined behaviors, but in general. Steel beams buckle of overloaded. Transistors overhead and explode outside of their SOA (safe operating area).

When engineers make something for the public, their job is to combine the unsafe bits, but make something which is safe, even against casual misuse.

When engineers make something for other engineers, that is less so; engineers are expected to read the data sheet.

> engineers are expected to read the data sheet

even if you know what the data sheet says, it's easier said than done, especially when the tool gives you basically no help. you are just praying people will magically just git gud.

Reply on news.ycombinator.com