To avoid memory-related bugs, C++ developers are often urged to switch to Rust. But is there an alternative?

A proposal was published in the September mailing of Working Group 21 (formed in 1990 with “accredited experts… who are interested in C++ work.”) since then, this “Safe C++ Extensions” proposal has been generating lots of discussion online…

It’s all evidence of a larger movement within the C++ community to explore new solutions for the 39-year-old programming language to address ongoing concerns over memory safety. This Safe C++ proposal is just one piece of an ongoing effort, with other ideas and approaches also being proposed and debated.

And the background for this conversation is an even larger demand in the wider programming community for more secure code… So first the new Safe C++ proposal acknowledges that ongoing criticism of C++ “dilutes the language’s value to novices.” But then it also argues that Rust’s exemplary safety model can be “an opportunity to strengthen C++”, adding that Rust’s decade-long work on memory-safety guarantees led the way and has very much informed the design of Safe C++.

“Adopting the same ownership and borrowing safety model that security professionals have been pointing to is the sensible and timely way to keep C++ viable for another generation.”

Proposing a Solution

The current version of Safe C++ took 18 months to design and implement, according to the proposal written by two very dedicated developers:

New York-based Sean Baxter, a developer whose career includes three and a half years as a software engineer at NASA’s Jet Propulsion Lab, followed by more than two years as an NVIDIA research scientist (according to his LinkedIn profile) — and the creation of an alternate compiler for C++ called Circle.
Sacramento-based Christian Mazakas, staff engineer at the C++ Alliance, a 501(c)(3) charity founded in 2017 to support the C++ community by encouraging new code libraries and language proposals as well as sponsoring educational initiatives.

The C++ Alliance announced its partnership with Baxter in September as “a revolutionary proposal that adds memory safety features to the C++ programming language.” The C++ Alliance’s president and executive director, Vinnie Falco, called it “a significant milestone in the C++ ecosystem, as the need for safe code has never been more pressing,” according to the announcement.

So, how do they implement it? A “key part” of the proposal is augmenting the standard library of C++ with what it calls the Safe Standard Library: “robust, memory-safe implementations of essential data structures and algorithms… By integrating these components into the C++ Standard Library, we can ensure that new code is written with safety in mind from the outset.”

As their document puts it, “The stick comes first… Safe C++ developers are prohibited from writing operations that may result in lifetime safety, type safety or thread safety undefined behaviors. Sometimes, these operations are prohibited by the compiler frontend, as is the case with pointer arithmetic. Sometimes, the operations are prohibited by static analysis in the compiler’s middle-end, which stops the use of uninitialized variables and use-after-free bugs, and it’s the enabling technology of the ownership and borrowing safety model. The remainder of issues, like out-of-bounds array subscripts, are addressed with runtime panic and aborts.”

But “the carrot is a suite of new capabilities which improve on the unsafe ones denied to users,” including new pattern-matching and sophisticated borrow-checking (tracking references to avoid the possibility of use-after-free vulnerabilities).

Evolving Toolchains

For Baxter, it’s been a very long-standing interest. Back in 2019, he created Circle, a new C++ compiler that he said delivers all the benefits of a full-fledged successor language by simply evolving the toolchain. And this approach is, by definition, fully compatible with existing C++ code. It was with Circle that Baxter first implemented a Rust-like borrow checker for C++ — but even then, Baxter was already showing a larger interest in the long-term fate of C++ code…

Announcing a new version of Circle in 2022, Baxter challenged those C++ detractors, saying the language is inherently broken/unsafe/slow to compile. “Software does what it does, and with effort, can be made to do something new. The techniques documented here extend C++ toolchains to fix language defects and make the language safer and more productive while maintaining 100% compatibility with existing code assets…

“The C++ of the future isn’t just a language. It’s a starting point for evolving programming towards greater safety, simplicity and productivity while staying interoperable with existing C++ assets.”

So why not just have everybody switch to Rust? The new Safe C++ proposal states its case. “The foreignness of Rust for career C++ developers combined with the friction of interop tools makes hardening C++ applications by rewriting critical sections in Rust difficult. Why is there no in-language solution to memory safety? Why not a Safe C++?”

A recent article by the Register runs through the history of warnings issued by everyone from researchers to Microsoft Azure CTO Mark Russinovich and eventually even America’s National Security Agency and the White House. And Baxter acknowledged to the site that “Recent government warnings about memory safety have made this a focus for the whole tech industry.

“I studied the theory and saw an opportunity, using new tooling, to help C++ engineers write more correct programs and eliminate the class of software defects most implicated in security vulnerabilities.”

Screenshot from Sean Baxter Twitter discussion about C plus plus

What Happened to Profiles?

It’s not the only idea for improving C++. 13 months ago, C++ creator Bjarne Stroustrup told attendees at CppCon that the language’s current situation was “an opportunity,” adding that from the earliest days of the language, type and resource safety have always been a goal. And Stroustrup proposed improving the language with profiles — safety-guaranteeing rules possibly checked by the compiler.

Some thought is already happening on profiles in the GitHub repository of the Standard C++ Foundation (a nonprofit backed by Microsoft, Google, and Intel). It has a page for C++ Core Guidelines edited by Bjarne Stroustrup and ISO C++ standards committee chair Herb Sutter. That page now includes references to “groups of related rules” (called profiles) for desired outcomes like like type safety and bounds safety.

“The profiles are intended to be used by tools but also serve as an aid to the human reader. We do not limit our comment[s] in the Enforcement sections to things we know how to enforce; some comments are mere wishes that might inspire some tool builder.”

But last Thursday (Oct. 24), Baxter announced a new paper titled “Why Safety Profiles Failed.”

“Safety Profiles were introduced in 2015 with the promise to detect all lifetime safety defects in existing C++ code. It was a bold claim. But after a decade of effort, Profiles failed to produce a specification, reliable implementation or any tangible benefit for C++ safety. The cause of this failure involves a number of mistaken premises at the core of its design.”

Here’s my draft for a paper “Why Safety Profiles Failed.”https://t.co/cfY2Vokfbr

I try to break down the lifetime safety problem in terms of:
1. aliasing
2. lifetimes
3. safeness

C++ doesn’t have information for any of these. Attempts to enforce safety are doomed to fail.

— Sean Baxter (@seanbax) October 24, 2024

The paper goes on to argue that as it is today, C++ source code “does not have sufficient information for achieving memory safety…” and recommends instead “incorporating Rust’s safety model into C++” (which would also improve the interoperability between Rust and C++ going forward). “By extending C++ with representations of all Rust constructs that can appear in function declarations (such as Rust enums, borrows and lifetimes, ZSTs, traits, etc) the number of common vocabulary types is greatly increased…

“C++ can be made memory safe, but not by dismissing everything that works, which is what the authors of Safety Profiles do.” The paper argues that C++ must “evolve to be more explicit in how it expresses aliasing, lifetime and safeness properties.”

A Collaborative Process

Discussions are happening — and there’s hopes for even more. Besides announcing the proposal, Baxter and the Alliance also announced they were “seeking feedback from developers, researchers, and other stakeholders,” believing that a collaborative process “will help refine the project’s scope and ensure that it addresses the most pressing needs of the C++ ecosystem.”

“With participation from industry, we could resolve the remaining design questions,” their proposal points out, “and in another 18 months have a language and standard library robust enough for mainstream evaluation. While Safe C++ is a large extension to the language, the cost of building new tooling is not steep… We’re co-designing the Safe C++ standard library along with the language extensions. Visit our repository to follow our work.”

And in June the domain “SafeCPP.org” was created — and now automatically redirects all visitors to a draft.html page for the Safe C++ proposal…