In a recent article, C++ expert and ISO C++ Committee Chair Herb Sutter expressed his views about what it takes to make C++ a safe language in the guise of Rust and other memory-safe languages (MSLs). His recipes include relying on tooling, as is the case with other MSLs, promoting safe language features, pushing unsafe features behind compiler flags, and more.
Sutter's starting point is the recognition of the importance of C++ becoming substantially safer by addressing the four main memory safety-related vulnerability categories. In fact, out of a total of twelve memory safety-related categories, accounting for about 70% of all CVEs, four of them root in out-of-bounds reads, out-of-bounds writes, null pointer dereference, and accessing freed memory.
According to Sutter, C++ already includes broad support for writing safe code and C++ literature has long identified key rules to apply to that aim. Yet, he believes, as a key language feature, C++ should strictly enforce those rules and make unsafe behavior available only if programmers explicitly opt out of standard rules.
Enabling safety rules by default would not limit the language’s power but would require explicit opt-outs for non-standard practices, thereby reducing inadvertent risks. And it could be evolved over time, which is important because C++ is a living language and adversaries will keep changing their attacks.
Sutter also describes a number of false problems and misconceptions, remarking how most high-severity CVEs are not related to memory safety (although out-of-bound writes are the first culprit); that MSLs also have their share of CVEs; that MSLs also rely on tooling like static analyzers and sanitizers, and others. So, the end goal cannot be for C++ programs to become completely free of memory safety-related CVEs, to enforce memory safety without relying on tools, or to make C++ code formally provable.
With his article, Sutter revived a conversation about C++ memory safety sparked by a 2023 NSA Cybersecurity Information Sheet recommending moving away from C/C++ as well as other memory-unsafe languages.
In response to the NSA report, Bjarne Stroustrup expressed his view that C++ can be as safe as Rust without the latter's complexities:
The work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains.
Here, Stroustrup was implicitly hinting at work the ISO Committee is carrying out regarding C++ profiles, which aim at making it possible to gradually adopt safer behavior and enforce it at compile-time.
A "profile" is a set of deterministic and portably enforceable subset of rules (i.e., restrictions) that are designed to achieve a specific guarantee. "Deterministic" means they require only local analysis and could be implemented in a compiler (though they don't need to be). "Portably enforceable" means they are like language rules, so programmers can count on different enforcement tools giving the same answer for the same code.
C++ profiles specifically encompass type safety, bounds safety, and lifetime safety. According to Stroustrup, code that conforms to a profile is safe by construction for the safety guarantees covered in that profile.
Stroustrup's critique of the NSA report did not go unnoticed and received some well-grounded criticism by Jimmy Hartzell, including the fact that C++ is not yet a memory-safe language and that areas like thread safety are not getting much consideration, whereas Rust already has many mechanisms related to it.
Now, even C++’s systems niche is under threat, with Rust, a powerful memory-safe programming language that avoids many of C++’s problems. Now, even the niches where C++ isn’t at all “legacy” have a viable, memory-safe alternative without a lot of the technical debt that C++ has.
Going back to Sutter's view, he also believes, as Stroustrup, that profiles are a key feature to make C++ safer and that 98% reduction in type/bounds/initialization/lifetime CVEs in C++ code is feasible all while preserving C++ promise:
I don’t want C++ to limit what I can express efficiently. I just want C++ to let me enforce our already-well-known safety rules and best practices by default, and make me opt out explicitly if that’s what I want. Then I can still use fully modern C++… just nicer.
At the end of his article, he suggests extensive and concrete directions the C++ ISO Committee could follow to reach the 98% goal. Do not miss it for the full details.