C++ creator calls for help to defend programming language from 'serious attacks'
- Reference: 1740937573
- News link: https://www.theregister.co.uk/2025/03/02/c_creator_calls_for_action/
- Source link:
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 [1]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.
[2]
The C/C++ community has responded with numerous proposals to move toward memory safety, including [3]TrapC , [4]FilC , [5]Mini-C , and [6]Safe C++ , to name a few.
[7]
[8]
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" ( [9]WG21 ) in support of his [10]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."
[11]
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 [12]Torvaldsian invective or hyperbole. The last time he used such emphatic language (that we're aware of) was back in 2018, when he [13]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!"
[14]
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 [15]Product Security Bad Practices report , issued last October.
Citing [16]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 [17]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."
[18]Linux royalty backs adoption of Rust for kernel code, says its rise is inevitable
[19]Time to make C the COBOL of this century
[20]Feds want devs to stop coding 'unforgivable' buffer overflow vulnerabilities
[21]Mixing Rust and C in Linux likened to cancer by kernel maintainer
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 [22]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 [23]secure-by-design practices – not just for ourselves but for the generations that follow," the ad biz [24]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 [25]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 ( [26]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…" ®
Get our [27]Tech Resources
[1] https://www.memorysafety.org/docs/memory-safety/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z8TjEP9jyF4FcyWCI7WKdAAAAEc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2024/11/12/trapc_memory_safe_fork/
[4] https://www.theregister.com/2024/11/16/rusthaters_unite_filc/
[5] https://www.theregister.com/2025/01/03/mini_c_microsoft_inria/
[6] https://www.theregister.com/2024/09/16/safe_c_plusplus/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z8TjEP9jyF4FcyWCI7WKdAAAAEc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z8TjEP9jyF4FcyWCI7WKdAAAAEc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[9] https://isocpp.org/std/the-committee
[10] https://github.com/BjarneStroustrup/profiles
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z8TjEP9jyF4FcyWCI7WKdAAAAEc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[13] https://www.theregister.com/2018/06/18/bjarne_stroustrup_c_plus_plus/
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z8TjEP9jyF4FcyWCI7WKdAAAAEc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] https://www.cisa.gov/resources-tools/resources/product-security-bad-practices
[16] https://www.theregister.com/2024/11/08/the_us_government_wants_developers/
[17] https://www.theregister.com/2022/09/20/rust_microsoft_c/
[18] https://www.theregister.com/2025/02/21/linux_c_rust_debate_continues/
[19] https://www.theregister.com/2025/02/18/c_opinion/
[20] https://www.theregister.com/2025/02/13/fbi_cisa_unforgivable_buffer_overflow/
[21] https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
[22] https://www.theregister.com/2024/10/16/google_legacy_code/
[23] https://blog.google/technology/safety-security/tackling-cybersecurity-vulnerabilities-through-secure-by-design/
[24] https://security.googleblog.com/2025/02/securing-tomorrows-software-need-for.html
[25] https://www.theregister.com/2024/08/03/darpa_c_to_rust/
[26] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[27] https://whitepapers.theregister.com/
Speed of Transition
Getting that speed right does indeed matter.
Rush too soon to Rust, and the world shortage of C/C++ programmers becomes total, we've still got billions of lines of code to look after for a long time to come with no one to maintain it. Draw it out too long, or take too long to add proper memory safety to C++, we'll be paying the price of not transitioning quicker.
It's almost as if there's the need for a plan. What could such a plan be?
Plan
I think it'd have to involve educators, projects, standards bodies and governments. Some sort of "date" would have to be set. Standards bodies would have to agree whether the future is Rust, or some sort of modified C++. Educators would have to start teaching C, C++ and Rust or modified C++ to degrees appropriate to where that generation of students are with respect to the "date". That is, keep teaching C/C++ before the date, start mixing in Rust or modified C++ as the data approaches and for a period aterwards (to make sure there's people comfortable with both), and then finally drop the C/C++ (unmodified) when the bulk of the work is done. Government would need to make Standards bodies and the education actually conform to the agreed plan and timescale, and nudge projects by procurement policy (i.e. an unimproved legacy OS gets banned from government services). Projects would have to commit to being ready-ish for "the date", or face becoming irrelevant.
An alternative plan - and one that a lot of C++ people seem to hope would pay off - is to somehow modified C++ to retain source code compatiiblity, whilst bringing in the safety benefits that we know other languages can readily achieve.
Reality
What actually seems to be happening is that Rust is unexpectedly good and hard to fault, is generating its own momentum (through the enthusiasm of the people using it), and everyone else is being left behind by the fast pace being set. Government is already pushing ahead with some heavyweight nudging. Which means, the C++ standards bodies and educators need to act now or be faced with a de facto Rusty future.
So yes, Bjarne Stroustrup's call for urgency is appropriate.
Thing is, it's going to be very hard to make C++ "competitive" with Rust in the "safety" stakes whilst also not totally breaking C++ source code and forcing a major re-write of source code anyway. That's a pretty narrow technical window to aim for, and a narrow window of opportunity time-wise. The odds are not in C++'s favour, I'd say.
C++'s Best Bet?
I think the thing that's probably best for C++ is to go all-in on the "safety" aspects of changes; add syntax to make it syntactically equivalent to Rust, remove old C++ syntax and all the trouble it causes, and force projects to do a lot of work if they want to use it.
That would make new C++ kind of a C++ homage to Rust. However, this could be a good thing. Rust's one weakness is that it is further removed from C/C++ syntax than is usual. Having all of Rust's tricks, whilst still resembling old fashioned C/C++ might make it a few friends.
And the nice thing is, such a language could be rapidly built as nothing more than a language translater that emitted Rust source code. This new C++ would be to Rust what TypeScript is a bit like to JavaScript; something a bit nicer, friendlier (and familiar), but totally fitting in with what's underneath.
C Dies Off
C's demise seems pretty hard to avoid, long term.
Re: Speed of Transition
The problem with memory safe C++ is the same with C++ vs C, it will always be backwards compatible. That means that all the ugly stuff from C is still possible in C++ and hence "memory safe C++".
Re: Speed of Transition
Isn't this the same problem Rust has ?
We write new pretty front ends in Rust or Super-Safe-C++ but they are calling 40 years of underlying library code written in C.
At least the Fortran libraries are safe
Re: Speed of Transition
The proposal is to add compilation flags to disable memory unsafe C and older memory unsafe C++ to be left with only the newer more memory safe C++ commands and classes.
It sems a much easier way to make existing software memory safe throw it out and rewrite in another language.
Re: Speed of Transition
Circle (the minor dialect change to the C++ LLVM compiler) by Sean Baxter's excellent research claims to have proven all the best bits of the borrow checker are possible with C++ today without substantially changing the whole language.
You can mark the security critical parts to under go this stricter checking with keyword that are in effect the opposite of rusts unsafe. This would obviously allow a suitably configured compiler to only allow 'safer' code or otherwise error.
So a path does exist that seems compatible with what exists, but the existing standards committee structure and viewpoint still has their head buried in the same. So maybe this recent announcement by Bjorne is to force them to chose a credible path. At the moment is is unclear what real world problem the profiles idea will be capable of solving or if it is enough to cover everyones needs. Is it still a talking point vapourware or is it implemented in at least one of the bug three compiler suites. So we can take it for a spin?
Its just a shame that Sean's work appears to be been self funded and has failed to see a commercial backer or see it being made available as open source available to all under existing compiler licenses.
Memory safety isn’t guaranteed to be consistent across all compilation units
If we're hoping to making progress with memory safety, we have to accept that at present the majority of compilation units will not be memory safe and that in future it would be unduly constraining for all memory-safe compilation units to be written in the same language.
We really need to focus on the semantics: the syntax du jour is then a matter of detail.
Failure to see
Stroustrup fails to see (or doesn't want to see) the simple fact that you can't retrofit C++ to become a memory safe language. A memory safe language requires a from-the-ground-up approach like Rust has been doing since day one.
He simply has to accept that C++ will one day be supplanted by Rust and other memory-safe languages but like most aging men he's trying to hold back the years and starting to look silly doing so.
I foresee the U.S. government mandating memory safe languages and microkernel operating systems for most of its critical computing tasks in the near future.
Re: Failure to see
I forsee the US government doing whatever Musk says and Microsoft/Oracle/IBM choose to deliver
And they all write it with AI and the cheapest labor they can find
Re: Failure to see
> Stroustrup fails to see (or doesn't want to see) the simple fact that you can't retrofit C++ to become a memory safe language. A memory safe language requires a from-the-ground-up approach like Rust has been doing since day one.
Well, Safe C++ (https://safecpp.org/draft.html) shows that you can have a C++ version of Rust, version that can be used as a migration path toward a memory safe language (IMHO this is a better alternative to Stroustrup's Profiles).
Re: Failure to see
> I foresee the U.S. government mandating memory safe languages and microkernel operating systems for most of its critical computing tasks in the near future.
Uh huh. Just like the DoD mandated "ADA FOR EVERYTHING" - remember how well that worked out?
I saw all sorts of things that had Ada call C that never came back, including missile guidance software. It ticked the "written in Ada" checkbox though.
Re: Failure to see
The US government currently couldn't mandate a piss up in a brewery. Maybe in four years time they can have another go, but by then C++26 will be out and the problem will be solved anyway.
Honestly, Rust simplifies a lot of things are the needlessly complex in C++. I'd rather have a non-memory safe Rust than a memory-safe C++. C++ was great for the time, but it has a lot of legacy cruft that newer languages have done away with.
I am not a young bloke. I learned C in 1991 (and was teacher's assistant too). Since then I've heards call to increase meory safety both in C and C++. And I suspect those calls were even older than that.
I read time and time again in BYTE Magazine and Dr Dobbs proposals for memory safety and garbage collection for C and C++
The standards bodies did not pick up any of those. And no compiler vendor presented a propiertary solution (but plenty of propiertary solutions for other stuff).
And now, after 34 years of innaction (from my perspective, I am sure the total innaction time is even bigger), ¿NOW they feel threatened and want the stadards bodies to pick up the pace?
Cry me a river. At least C is mildly ussefull, C++ can die in a (dumpster) fire.
¡Real Memory Safety from the ground up (instead of bolted on memory safety after the fact) for the win!
Enforcement; Syntax does matter
I sympathize with the C/C++ folks, I really do. Even though I've designed and implemented a couple of replacement languages (Draco and Zed). If someone is really good at something, they are likely happy with that. Any change is going to to take away from that. Those at the very top of the game will be impacted the most. Those just learning may not much care what language they use. If you know the syntax, semantics and rules of several languages, you probably aren't *really* good with any of them. "Jack of all trades, master of none." The human brain can only do so much.
So, forcing C/C++ wizards to change to another language is going to cause them a lot of pain, and reduce their productivity. So, adding rules, etc. to the language they are a wizard in is perhaps less painful for them. BUT. It *must* be enforced. Expediancy or a bit of efficiency cannot be used as an excuse to violate the new rules. And yes, management must be in agreement on this, because it will affect their plans and schedules, and *those* cannot be allowed to force rule violation.
If someone comes up with a new language that can solve the problems, I believe it should not attempt to look too much like C/C++. The reason is that the similarity can trick the experienced programmers into doing things that the new rules will prevent. => frustration. But, I believe the "style" of the new language syntax should be similar to what the programmers are used to. Changing the style of function headers, declarations, etc. shouldn't be done just because you can. There must be real advantages. For example, I really don't like the "." cascades that Rust seems to encourage - the code is ugly to my eye.
Most folks know that C/C++ declarations are awful. The "cdecl" program that translates between C syntax and English was written long ago, so the need isn't a new one. Swapping things like which side the "*" goes on makes a big difference - lots less parentheses needed.
PR Wars
From TFA: 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.
"Narrative" == modspeak for, "story" (which may be partial, or complete, bullshit).
We don't need PR wars adding noise to the issue.
C++ (and C, and other computer languages) are not things which need to be "defended". They're either fit for their purposes, or they are not.
The bounty of buffer overflow and unsanitized/unchecked input string vulnerabilities we're seeing these days is the fruit of decades of "economic race-to-the-bottom" managerial decisions which have reduced/eliminated proper instruction and training of programmers, demanded projects be completed in unreasonably-short time, outsourced programming to offshore companies, whose managers also have reduced/eliminated proper instruction and training of programmers, and demanded projects be completed in unreasonably-short time.
Adding poor working conditions and pay (YMMV, substantially) incentivises programmers to not give a flying fuck, so those who know they ought to put in various checks, do not, because they answer to managers whose primary concern is being able to tick the "done" box on some spreadsheet, come Friday afternoon.
> C and C++ rely on manual memory management
C++ does not rely on manual memory management.
When Rust and C++ interface with C libraries, then they all rely on manual memory management. This is where the errors creep in; Rust just hasn't been battle tested yet.
O/T but a brilliant quote:
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.
Bjarne Stroustrup (1950- )