Comment by Shawnecy | Hacker News Reader

Comment by Shawnecy | Hacker News Reader

Parent Full thread

About a year ago, Stroustrup wrote a similar response[0] to a similar statement from the NSA[1].

I wasn't really convinced and am more in agreement with this response to Stroustrup[2] from an embedded Linux developer. To quote from near the end of their response to Stroustrup:

> In the meantime, it is unfair for Dr. Stroustrup to call safe programming languages novelties or to pretend that C++ isn’t already far behind the times on this. This was already an important criticism of C++ decades ago, when Java first came out in the 90’s and was referred to as a “managed programming language.”

I'm not really buying that C++ is really all that commonly safe when we have stats like these[3]:

> A recent study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues. Google estimated that 90% of Android vulnerabilities are memory safety issues. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues 1.

> The Slammer worm from 2003 was a buffer overflow (out-of-bounds write). So was WannaCry (out-of-bounds write). The Trident exploit against iPhones used three different memory safety vulnerabilities (two use-after-frees and an out-of-bounds read). HeartBleed was a memory safety problem (out-of-bounds read). Stagefright on Android too (out-of-bounds writes). The Ghost vulnerability in glibc? You betcha (out-of-bounds write).

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...

[1]: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

[2]: https://www.thecodedmessage.com/posts/stroustrup-response/

[3]: https://www.memorysafety.org/docs/memory-safety/

> I'm not really buying that C++ is really all that commonly safe when we have states like these[3]:

It's not. At this point, I cannot in good faith say that he is not lying, either to us or himself.

I don't think he's lying to us. I think he genuinely believes that everyone is using it wrong.

Although that's not much of a defense when he was the one who invented the wrong ways to use it.

It's hard to get a man to understand something when his salary (or hobby or self-image) depends on his not understanding it.

It’s probably not a coincidence that he’s the author of the famous quote that may and is often used to deflect any and all criticism of a programming language.

C and C++ are HARD to use correctly, but how many of those 60-70% vulnerabilities would have been resolved by just compiling with llvm address sanitizer? It would have stopped virtually all of them?

https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://clang.llvm.org/docs/AddressSanitizer.html

In many cases we already have the tools. The problem is that people are not using them.

That said it is still in general a good thing to steer people away from C / C++ due to the languanges being very hard to use correctly.

> In many cases we already have the tools. The problem is that people are not using them.

The problem with these tools are that the instrumentation code inserted by the compiler comes with a 50-100% program-wide performance loss (*) and that's not acceptable to C++ developers. So in practice, you don't just add -fsanitize=address to your builds, you add it to test builds and fuzz them. But now you're not just trusting your compiler, you're trusting your tests and coverage.

The promise of Rust is that many of the memory safety bugs are forbidden at compile time in safe code, and the stuff that has to be checked at runtime (self referential data structures, out of bounds, etc) is able to be added more granularly with unsafe opt-outs where appropriate which means that you're not going to pay 50-100% in raw performance.

* take this like all perf numbers with a heap of salt, do your own benchmarks and come to your own conclusions.

To developers that cargo cult performance, that is.

I have always enabled bounds checking, and never ever, did it matter for the kind of projects I was involved with.

Not everyone is really writing a VR engine for a console rendering at 120 FPS, but just like everyone wants to be Google, so do much of those developers.

> It would have stopped virtually all of them?

Do you have a source for that claim?

The problem is that there are more compilers out there than clang, and clang isn't available everywhere.

asan only catches what your test suite covers. specifically, that doesn't include novel attacks.

That's kinda true, but if you use the compiler inserted address sanitizer code it will turn bugs from exploits into crashes. You can't exploit a OOB write if the write fails and the program crashes.

if you can afford the cost of that, just write your program in any other language c with asan is a lot slower than the safe alternatives

I made another comment about exactly that, but was addressing the concern that asan doesn't make code safe.

They are hard to use when you absolutely want to use them the hard way, std::span can provide you lots of safety, but people don't use available tools.

It provides none, unless you are using C++26 compiled with hardned standard library mode.

If you care about safety use gsl::span instead.

Significantly though - almost all of those are in C code, even if C++ is used elsewhere in the program.

C++ does no good if you don't #pragma GCC poison all the C-isms.

Reply on news.ycombinator.com