Bjarne Stroustrup, creator of C++, has issued a call for the C++ community to defend the programming language, which has been shunned by cybersecurity agencies and technical experts in recent years for its memory safety shortcomings.

C and C++ rely on manual memory management, which can result in memory safety errors, such as out of bounds reads and writes. These sorts of bugs represent the majority of vulnerabilities in large codebases.

With the high-profile, financially damaging exploitation of these flaws, industry and government cybersecurity experts over the past three or four years have been discouraging the use of C and C++ while evangelizing languages with better memory safety, like Rust, Go, C#, Java, Swift, Python, and JavaScript.

The C/C++ community has responded with numerous proposals to move toward memory safety, including TrapC, FilC, Mini-C, and Safe C++, to name a few.

But with Stroustrup, professor of computer science at Columbia University, raising the alarm, it’s clear the issue is not just slow progress but the absence of a public narrative that can compete with the tech industry’s adoration of Rust.

In a February 7 “Note to the C++ Standards Committee” (WG21) in support of his Profiles memory safety framework, he wrote, “This is clearly not a traditional technical note proposing a new language or library feature. It is a call to urgent action partly in response to unprecedented, serious attacks on C++. I think WG21 needs to do something significant and be seen to do it. Profiles is a framework that can do that.”

His note continues, “As I have said before, this is also an opportunity because type safety and resource safety (including memory safety) have been key aims of C++ from the very start.

“I feel strongly about this. Please don’t be fooled by my relatively calm language.”

Stroustrup is not known for Torvaldsian invective or hyperbole. The last time he used such emphatic language (that we’re aware of) was back in 2018, when he asked the C++ community to slow down and propose language improvements in a more coordinated manner. “We are on the path to something that could destroy C++,” warned at the time “We must get off that path!”

In a February 13 message to the security-focused SG23 mailing list, addressing skepticism that there’s a threat to C++, Stroustrup pointed to US govt’s CISA’s Product Security Bad Practices report, issued last October.

Citing the report’s guidance that by January 1, 2026, manufacturers should have a memory-safety roadmap for products using memory-unsafe languages that leads to the elimination of memory safety vulnerabilities, or should adopt a memory safe programming language, Stroustrup observed, “I consider that a credible threat.”

Traveling abroad at the time this story was filed, Stroustrup told The Register he would like to elaborate further on the matter but expressed concern that a hasty response might be misunderstood or taken out of context. But he endorsed the inclusion of his mailing list remarks.

Stroustrup is well-aware of the growing emphasis on memory-safe programming, having addressed these concerns directly in 2022, in response to Microsoft Azure CTO Mark Russinovich’s call “to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-[garbage collected] language is required.”

Brushing off Russinovich’s remarks as infatuation with a shiny, new language, Stroustrup responded, “Safety is obviously critically important in many contexts, so I have worked on increasing safety in C++ for years.”

He called for an evolutionary approach – modernizing C++ code to make it safer with tests and tooling – rather than a revolution that throws C++ out the window.

That’s a position Google has supported with its acknowledgement that legacy C and C++ will be around for years and needs to be managed.

But just this week, the Chocolate Factory made it clear it’s more focused on a memory-safe future than modernizing C/C++.

“[W]e are calling for a fundamental shift: a collective commitment to finally eliminate this class of [memory safety] vulnerabilities, anchored on secure-by-design practices – not just for ourselves but for the generations that follow,” the ad biz said.

Given CISA’s call to deprecate C/C++ by 2026, there’s not a lot of time left for the C/C++ community to respond.

Robin Rowe, who’s helming the TrapC project, doesn’t believe Profiles will arrive in time or that they’re a practical answer.

“If you mark your code to enforce a Profile, some features of the C/C++ language will stop working,” he told The Register. “It’s like -Wall and -Wextra compiler flags in Linux, except instead of escalating warnings into errors, it turns off pointers or arrays.”

C++ coders would mark their code with a Profile and then rewrite portions that break due to the Profile’s restrictions, Rowe explained.

“For example, a C for-loop that iterates over an C array must be replaced with a C++ for-each loop that does the same using a std::vector,” he said, calling it a regime to force C++ programmers to rewrite their code using the latest C++ Core Guidelines.

“Nobody has said to expect C++ Profiles to become standardized by the ISO C++ Committee, or to be implemented in a compiler, before 2026,” Rowe said, who also doubts that DARPA’s TRACTOR project, for automated C-to-Rust conversion, will be ready by then.

Rowe has a horse in this race – he recently presented his work on the TrapC compiler, which he expects will be ready later this year, to the ISO C Committee as a potential extension to the C programming language. On Thursday, February 27, he answered questions about the project during the ISO C Committee standards body meeting in Graz, Austria.

“TrapC Memory Safe Pointers (MSP) will not buffer overrun and will not segfault,” he said. “When C code is compiled using a TrapC compiler, all pointers become MSP and are checked.”

Rowe argues that other C and C++ memory safety schemes are not comprehensive. “The vulnerability of programmer-configurable C/C++ programming language subsets, whether it’s C++ Profiles, C extension N3211 or others, is that memory safety isn’t guaranteed to be consistent across all compilation units,” he explained.

Rust is not immune, is also vulnerable

“With subsets it is too easy to create an unsafe hole where memory usage goes unchecked in what is supposedly memory safe code. Rust is not immune, is also vulnerable. Rust programs may open a hole using the Rust ‘unsafe’ keyword, and widely do so to access notoriously unsafe C pointers.”

David Chisnall, a visiting researcher at the University of Cambridge and director of systems architecture for SCI Semiconductor, which makes memory safety hardware based on Capability Hardware Enhanced RISC Instructions (CHERI), voiced skepticism about language–level solutions to memory safety in response to Stroustrup’s SG23 call to arms.

“Very few things are written in a single language these days and memory-safety across languages is important,” he wrote. “If you write a Rust core with Lua scripting, but Lua doesn’t respect Rust’s unique ownership model then that makes it very hard to interoperate safely. Tools for safe interoperation are important.”

Chisnall argues that making C and C++ safer is a better approach than rewriting code in Rust or some other memory-safe language.

Rewriting billions of lines of code all at once is a problem

“Incremental migration from C to current C++ to C++ with stronger safety is a great story because you can do it one piecemeal,” he explained.

“Rewriting billions of lines of code all at once is a problem: Even if the end result is memory safe, rewriting code introduces bugs and a lot of those will be safety or security critical. Selling a migration story from C to a safe C++ dialect that people can do a little bit at a time over multiple years would be great for C++.”

It remains to be seen who will be the author of that story.

That is, if memory safety remains a government concern. As Chisnall observed, “The new US administration has removed everything from the White House web site and fired most of the CISA people who worked on memory safety…” ®