Hacker News Reader

Comment by mraison | Hacker News Reader

Nowadays when that sort of bug is discovered, the question that naturally comes to my mind is "would that have happened if the software were implemented in (safe) Rust"? In that case it looks like the answer is no.

Of course 7-zip is much older than Rust so that's just a thought experiment.

View on HN

Comments like this hurt the adoption of Rust by making the community seem hopelessly naive. It's just how people make the Go community look bad by acting like Go invented CSP.

Rust is a (very?) good language that I hope will see more adoption but it is not the first memory safe language. Garbage collected languages are perfectly appropriate in many situations. Ada is almost 40 years old.

Why is wondering “could another tool have solved this problem” come across as “hopelessly naïve?”

It didn’t say Rust was the first. It also acknowledged that there’s great reasons it’s currently not used here.

Memes about programming languages (and programming language communities) die hard so it's probably a good idea to avoid reinforcing them when possible. I read this comment as a sort of implicit variant of "RIIR". Judging by the downvotes, I think others did the same.

Rust probably doesn't even deserve the "RIIR" meme as 1) "RIIR" seems to happen way more often on HN/similar than on mailing lists or bug trackers and 2) much of the time the person saying "RIIR" admits to not even being a Rust programmer themselves. I think it's just a side effect of Rust (justifiably) emphasizing safety, and by extension security, in its presentation, and the tendency of some people to conflate the elimination of a certain class of vulnerabilities with the elimination of all vulnerabilities. To be fair, this poster didn't make this mistake.

Edit: Another mistake that some people make after being introduced to Rust is assume that languages that don't explicitly emphasize memory safety in their presentation aren't memory safe. This poster comes across as potentially making this mistake.

Thanks, that makes sense. I’m very interested in these kinds of perceptions, so I appreciate you taking the time.

Of course same is true for modern cpp.

Modern C++ does not mandate that every value be a valid instance of its type wherever it is theoretically accessible, so I'm not sure why you're saying modern C++ fixes this. Actually, the fact that Rust does is something people somewhat regularly complain about. It is a heavy-handed performance / code complexity vs. safety tradeoff that certainly fixes this bug, which I think is a pretty reasonable thing to point out.

If you follow C++14 core guidelines, the defect described would not have occurred. The bug at its core is usage of unsanitized input data. You don't need to "mandate that every value be a valid instance of its type wherever it is theoretically accessible", however that may differ from simple sane C++14 paradigms.

OPINION ALERT: Honestly guys get over rust, it does not offer a single advantage in real-life programming scenarios.

I disagree with people who think Rust is a savior, but it does have plenty of advantages in some areas over C and C++, especially for novices.

So I have to read a 21762 line document just to avoid shooting myself on the foot?

There's a Rust advantage right there.

Who said anything about reading a document?

The guidelines seem like a document to me: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

You don't have to read them. The compiler will enforce them.

Oh, ok, I didn't know that, thanks. Enforcing guidelines seems a bit like a contradiction in terms :)

The C++ compiler can't enforce many of these rules (and many of the ones it does claim to enforce, it only does heuristically), and the document itself is not shy about admitting that. It also makes quite clear that it expects not just mechanical checking, but things like peer review, to take these guidelines into account--meaning yes, you are expected to know a large portion of the document. Also, a lot of the listed enforcement mechanisms are literally just flagging suspicious code--you would have to disable a tremendous number of such flags to execute many perfectly reasonable programs. Stop misleading people about the contents of this document actually being enforced by the compiler, please.

D also addresses buffer overflows in a mechanically checkable manner.

Reply on news.ycombinator.com