The Empire Of C++ Strikes Back With Safe C++ Blueprint

After two years of being beaten with the memory-safety stick, the C++ community has published a proposal to help developers write less vulnerable code.

The Safe C++ Extensions proposal aims to address the vulnerable programming language's Achilles' heel, the challenge of ensuring that code is free of memory safety bugs.

"This is a revolutionary proposal that adds memory safety features to the C++ programming language," Vinnie Falco, president and executive director of the C++ Alliance, said Thursday. "This collaboration marks a significant milestone in the C++ ecosystem, as the need for safe code has never been more pressing."

It has never been more pressing because for the past two years, private and public sector organizations have been pushing programmers to write new applications and rewrite old ones in memory safe languages such as C#, Go, Java, Python, and Swift, but particularly Rust because it's a performant low-level systems language.

Software engineer Alex Gaynor raised the issue back in 2019, noting that the majority of serious vulnerabilities in large codebases come from memory safety flaws such as buffer overflows and use-after-free. "The data bears out, over and over again, that when projects use memory unsafe languages like C and C++ they are burdened by an avalanche of resulting security vulnerabilities," he wrote.

Memory safety subsequently became a common subject of discussion in academic papers and at technical conferences. By September 2022, Microsoft Azure CTO Mark Russinovich called for deprecating C and C++ and adopting Rust.

A few months later, the NSA took a similar position. By 2023, memory safety had become a mainstream topic, covered by Consumer Reports.

Those involved with C++ became defensive. Two years ago, in response to Russinovich's call to dump C/C++, C++ creator Bjarne Stroustrup told The Register, "We can now achieve guaranteed perfect type and memory safety in ISO C++."

Yet that claim was met with some skepticism. Josh Aas, co-founder and executive director of the Internet Security Research Group (ISRG), which oversees a memory safety initiative called Prossimo, last year told The Register that while it's theoretically possible to write memory-safe C++, that's not happening in real-world scenarios because C++ was not designed from the ground up for memory safety.

The Safe C++ Extensions proposal aims to address that criticism and to respond to public sector demand for memory safety from the NSA and the other Five Eyes intelligence agencies, the US Cybersecurity and Infrastructure Agency (CISA), the White House, and the DARPA.

• The future of software? Imagine a bot, stamping on a human face – forever
• Google says replacing C/C++ in firmware with Rust is easy
• Security boom is over, with over a third of CISOs reporting flat or falling budgets
• LLM-driven C-to-Rust. Not just a good idea, a genie eager to escape

In August, Gaynor revisited the topic of memory safety by noting that while it makes sense to try to make C++ safer, he has doubts about the extent to which that's possible.

"It is clear, I think, that there are substantial safety improvements possible for C++," he wrote. "In particular, entirely solving spatial safety appears to be within reach. Alas, I think it is equally clear that making C++ as safe as Swift or Go or Rust is not something we know how to do, nor does it appear likely that we’ll be able to find a simple solution."

Nonetheless, the Safe C++ Extensions proposal aims to have a go. Acknowledging the now deafening chorus of calls to adopt memory safe programming languages, developers Sean Baxter, creator of the Circle compiler, and Christian Mazakas, from the C++ Alliance, argue that while Rust is only popular systems level programming language without garbage collection that provides rigorous memory safety, migrating C++ code to Rust poses problems.

"Rust lacks function overloading, templates, inheritance and exceptions," they explain in the proposal. "C++ lacks traits, relocation and borrow checking. These discrepancies are responsible for an impedance mismatch when interfacing the two languages. Most code generators for inter-language bindings aren’t able to represent features of one language in terms of the features of another."

Though DARPA is trying to develop better automated C++ to Rust conversion tools, Baxter and Mazakas argue telling veteran C++ developers to learn Rust isn't an answer – a point that a C-focused Linux kernel maintainer made recently.

"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," they contend. "Why is there no in-language solution to memory safety? Why not a Safe C++?"

The foreignness of Rust ... makes hardening C++ applications by rewriting critical sections in Rust difficult

Baxter told The Register that while generating provably correct programs has been a matter of interest among computer scientists for decades, the issue has been elevated to a national priority.

"Recent government warnings about memory safety have made this a focus for the whole tech industry," said Baxter. "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."

The Safe C++ project adds new technology for ensuring memory safety, Baxter explained, and isn't just a reiteration of best practices. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety."

Baxter said that rewriting a project in a different programming language is costly, so the aim here is to make memory safety more accessible by providing the same soundness guarantees as Rust at a lower cost. "With Safe C++, existing code continues to work as always," he explained. "Stakeholders have more control for incrementally opting in to safety."

The next step, Baxter said, involves greater participation from industry to help realize the Safe C++ project.

"The foundations are in: We have fantastic borrow checking and initialization analysis which underpin the soundness guarantees," he said. "The next step is to comprehensively visit all of C++'s features and specify memory-safe versions of them. It's a big effort, but given the importance of reducing C++ security vulnerabilities, it's an effort worth making." ®