| Bjarne Stroustrup was recently interviewed by Ryan Peterman^1 1. https://youtu.be/U46fJ2bJ-co?t=2780 and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either 1. Being written in C style C++ and not using "Modern C++"
2. Being written in C He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues. I'm not a C++ guy, so how much of this is true? What do the C++ developers think about this? I've postd the whole message if people would like to read. It's about 46minutes into the video Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that
exist there. Bjarne:
I'm so tired of that. Um I haven't had those problems for years. Um, and
somebody did a a study of the obvious problems with buffer
overflows and um people hacking in using that kind of
stuff and uh almost all of the uh these cases when
people writing C style code or in C and uh Herb Server has a a talk with
with actual numbers and they they are quite significant. It's it's sort of
that kind of problems more than 90% are for people that don't
write modern C++. They they use raw pointers to pass
things around without um the number of elements. No fat pointers, no spans.
um you you have them in C++. You can use them. You can use uh vectors. We have
hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it.
Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a
hardened option that are standard. uh and the work I'm doing on profiles will
give you a way of guaranteeing that you don't do the stupid things.
Um so anyway, uh fundamentally
theoretically the problem was solved many years ago and people just do what
they've always done and get the problems they've always had. And uh that makes me
sad and uh it's one of the things that makes me work on uh coding guidelines
and on enforced profiles and on education. I mean education is one way to solve the
problem. Is there a way to get the compiler to just prevent people from
doing all those risky things? And is that enabled by default in modern C++ today?
No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of
that should have been in in in uh C++ 26, but there are still a lot of people
even in the C++ standards committee that are very devoted to uh their old code
and their old ways of doing things. Um there's people who says you should only
standardize what is common in industry. But when the bugs are common in
industry, you should do something else. The standards committee is a a topic I |
> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code
Maybe the android team could have gotten the same benefits by simply auditing and modernising their C++ code? I'm not convinced. Google has some amazing engineers. They've been using hardened standard library variants for a long time - much longer than they've been part of the C++ standard. If google is still getting large security benefits from adopting rust, I think the benefit in rust is real and Bjarne Stroustrup is wrong.
[1] https://blog.google/security/rust-in-android-move-fast-fix-t...