C++ is under attack. Some argue that it is the language’s fault, with those pointers and rules and complexity and undefined behavior, and try once and again to develop a “C++ killer” language, with various degrees of success. Others (rightfully so) defend the language (and its community) by acknowledging its history, its flaws, and proposing ways forward. The former group makes headlines in Reddit and Medium. Instead, the Vidéothèque entry of this month tells the story of a prominent member of the latter group, a certain Herb Sutter.
The video in question is a keynote Herb gave at the ACCU 2024 conference: “Safety, Security, Safety (sic) and C/C++ (sic)”. The ACCU conference describes itself as
…one of the longest running developer conferences in the world. Established by the ACCU organization in 1997 it has always been open to the whole community and at the forefront of what’s happening in the world of software development.
Originally focused on C and C++, that community has expanded to include other language ecosystems, and you should expect to be exposed to content on C#, D, F#, Go, JavaScript, Haskell, Java, Kotlin, Lisp, Python, Ruby, Rust, Swift and more. There are always sessions on TDD, BDD, and how to do programming right.
The name of Herb Sutter has appeared several times in the pages of this magazine, and with reason: he is the author of the often-cited “Free Lunch is Over” March 2005 article on Dr. Dobbs’ Journal (of which, thankfully, the Internet Archive has taken snapshots of page 1, page 2, and page 3). He is a remarkable member of the C++ committee, and a former Microsoft employee where he worked as lead architect of (you guessed it) the C++ compiler. He is also author and co-author of various books in the field. Last but not least, Herb is currently working on a project called cppfront, where he explores mechanisms to make C++ a safer language, without ditching 40 years of heritage in the process.
TL;DR: Herb knows a thing or two about C++.
In his keynote, Herb starts by acknowledging a series of sins (maybe the word is too much?) committed by the C++… committee. First and foremost, the language was designed to put performance ahead of safety. This is a historic fact, and as such it carries into the present with a lot of consequences, including the much dreaded “C/C++” moniker, thereby providing the fertile ground for a long series of safety issues making the headlines today.
Second, yes, the community has adopted the ostrich’s attitude, and has repeatedly tried to bury its head in the sand to avoid looking at the problem. The consequence is easy to see: C and C++ are both, despite their immense contributions during the past 40 years, unjustly thrown under the bus and almost completely ditched by a whole generation of software developers blinded by the word “Rust” on the title of every popular podcast episode.
Objection, your honor.
Let us be very clear: what Herb does in this talk is nothing short of uncommon, and strictly follows our wish for less evangelization, and more honestization, which we expressed in a previous article on this magazine. Mature communities, just like mature individuals, are able to take ownership of their flaws, and grow.
Case in point: the week Herb gave this talk at ACCU, Rust had disclosed a very severe vulnerability; Herb does not talk about it specifically, to (very cleverly) avoid having online hordes dismiss his talk as a bashing of Rust and a glorification of C++. The truth is more subtle than that: the Rust culture treats bugs more seriously than C++! For example, CVE-2022-21658, is a problem similar to its buggy C++ equivalent std::filesystem::remove_all
, but the latter (suprise!) has no CVE report.
For Herb, in this case, the key task consists in turning around the philosophical and cultural focus of C++: instead of guaranteeing performance first and making safety optional, he proposes to embrace safety profiles and to guarantee safety first, and making performance optional.
Repeating it loudly for the people in the back: the problem is not technical, but cultural.
(For more information about the WG21 safety profiles’ framework, there is an interesting paper by Stroustrup & Dos Reis called “Design Alternatives for Type-and-Resource Safe C++”.)
C++ was born in an era of underpowered PCs, and it largely succeeded as a remarkable language that provided a very high-level of abstraction for developers, all while generating blazingly-fast code for those same sluggish computers. The tables have turned, and in our modern world, filled with bad actors and cyber warfare scenarios, C++ will have to evolve as well: its focus has to change. Google is worried about it. Apple is worried about it. The White House is worried about it. The NSA is worried about it. Consumer reports is worried about it.
You get the idea.
The goal, then, is to make C++ approach safety parity with other languages such as Go, Rust, C#, or Python, in four specific areas: type safety, bounds safety, initialization safety, and lifetime safety. Just like with Rust, giving C++ developers a mode that improves safety by default won’t save them, but it will help them.
The situation is dire. Our modern world infrastructure is running on insecure software, and examples of breaches and vulnerabilities abound. Herb makes four major points that stand out in his keynote:
In the MITRE Corporation Common Weakness Enumeration (CWE) 2023 ranking, we see 3 vulnerabilities directly related to C++: out-of-bounds write, use after free, and out-of-bounds read. Those are the targets to eliminate at this point. However… caveat emptor: the most important attacks in the past few years are not related to memory safety: neither SolarWinds, Log4Shell, DarkBeam, nor the XZ utils backdoor are.
Speaking about which, Herb quotes an an article by Bruce Schneier about the XZ Utils backdoor attack where he states a chilling conclusion:
I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals.
- Moving safety “to the left”, closer to developers and their “inner loop”, is a fundamental task, and one shown by Rust to be a major step towards overall code safety. Herb quotes David Chisnall and his January 2024 message “The Case for Rust (in the base system)” on the freebsd-hackers mailing list:
Between modern C++ with static analysers and Rust, there was a small safety delta. The recommendation was primarily based on a human-factors decision: it’s far easier to prevent people from committing code that doesn’t compile than it is to prevent them from committing code that raises static analysis warnings. If a project isn’t doing pre-merge static analysis, it’s basically impossible. Between using modern C++ (even just smart pointers and ranges) and C, there is an enormous safety delta.
- Herb debunks a common myth: no major programming language is formally provably type-safe! Yup, not even Java or C# (both with use-before-init and use-after-dispose problems), or Rust or Go, which come bundled with sanitizers, but people not always use them. Remember, it is not the types that will help you:
A programmer with an expensive type system does not write better programs, any more than a novice guitarist becomes a stadium-grade shredder by buying a fancy guitar.
- Last but not least, Herb acknowledges that Rust is the only major language with strong concurrency safety guarantees… but did you know that 30 to 50% of all Rust crates use some unsafe code at some point or another, versus just 25% of Java libs? Things are not always what they seem.
To further his defense, Herb provides a single, fundamental, modern code example that shows the levels of evolution reached by C++ today. Hang tight:
auto a = make_unique<Widget>();
Boom. The code above, compatible with C++14 and later, is type-safe, bounds-safe, initialization-safe, and lifetime-safe by default. Now go back and re-read the previous sentence, twice.
Even better, the code above uses type inference, a sign of the times. And yes, it is compatible with the most modern C++ compilers available today. Maybe the problem is not so much C++ being unsafe, but the way C++ is taught in schools, and the way it used by most organizations. Maybe it is time to review your coding guidelines? Just saying.
Bjarne Stroustrup agrees with Herb:
That (report) specifically and explicitly excludes C and C++ as unsafe. As is far too common, it lumps C and C++ into the single category C/C++, ignoring 30+ years of progress. Unfortunately, much C++ use is also stuck in the distant past, ignoring improvements, including ways of dramatically improving safety.
Herb ends the first part of his keynote with some important calls to action, which we repeat here for the sake of sanity and correctness:
- Use language static analyzers and sanitizers (yes, even if you say “I’m using a safe language!”)
- Keep your tooling updated.
- Secure your software supply chain as much as possible.
- Use modern package managers.
- Generate and store SBOMs (Software Bills of Materials) together with your build artifacts.
- Don’t store secrets on code (duh! Yet…)
- Configure servers properly.
- Keep non-public data encrypted.
- Keep your threat modeling up-to-date, because attackers will find new weak spots all the time.
Herb ends this talk with a short of his cppfront project, in particular the current efforts to get faster compile-time support for regular expressions, highlighting the contributions of Hana Dusíková.
(By the way, the name “cppfront” sure brings memories of “cfront”, the first compiler for a C++ predecessor called “C with Classes” written by Bjarne Stroustrup in 1983.)
We can laugh at C++ developers all we want, but the committee and its surrounding community are doing an admirable job, and have done it for more than 35 years. C++ is robust, cross-platform, safe, has a vibrant ecosystem, very stable tooling, and has a brilliant (and safe) future ahead.
For more information about the current state of the “safe programming language wars” (let us throw some fuel to the flames, shall we?) we can recommend “A New Era for C and C++? Goodbye, Rust?”. If you are new to C++ and would like to write safe code, avoid these common “31 nooby C++ habits you need to ditch” and change your perspective.
If you are interested in the history of C++, we suggest watching this lecture by Bjarne Stroustrup, “The Design of C++” recorded in March 1994, providing an interesting view not only on the language, but also a candid perspective on its creator.
Watch this month’s Vidéothèque article, “Safety, Security, Safety (sic) and C/C++ (sic)”, by Herb Sutter, on YouTube.
Cover snapshot chosen by the author.