An Alternative to Rewriting Memory-Unsafe Code in Rust: the 'Safe C++ Extensions' Proposal

"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," reports the Register.

"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..." 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 the 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... 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."

Complicate much?

[JamesTRexx]

"Rust lacks function overloading, templates, inheritance and exceptions,"

They say this as if it's a bad thing.

Re:

[Waffle Iron]

They also didn't mention that Rust does have macros (lisp-ish macros, not silly string substitutions like C macros). These are used for many of the things that would be done with templates in C++.

Re:

[caseih]

It is if you want to migrate a C++ application over to something safer. A complete rewrite is not always feasible.

Circle C++ is pretty impressive. I'm glad to see the ideas developed there move into mainstream C++. From what I've seen in Circle, this should dramatically reduce the learning curve for C++ developers.

Re: Complicate much?

[OrangeTide]

That's the price of making the mistake of writing stuff in C++ in the first place. Seven the technically debt has to be paid somewhere.

Re:

[Joce640k]

The only thing unsafe about C++ is letting C coders use it.

Re:

[HighPerformanceCoder]

I depend on all of those things. I'm a bit surprised, though, I thought Rust had templates at least.

Re:

[Pieroxy]

Moreover, adding safe extensions to C++ will get manager the stamp they need as "having a safe language" while nothing will be done on the project to actually adhere to these extensions. Migrating your C++ code to these extensions will require a major rewrite of your app, while still not guaranteeing everything is safe in your codebase.

Re:

[Scythal]

Those are quite annoying limitations, indeed. Templates aren't really a major concern, and I understand the issue with exceptions - they're thinking about removing unwinding, too. But overloading and inheritance are quite important concepts in a modern language, so it's weird they're so fierce about it when it can make the code much cleaner (no wonder the GUI frameworks are so cumbersome in Rust). I see many people are very confused about inheritance. I think it comes from a misinterpretation of what the Ga

I think they just hate how physical memory works..

[dowhileor]

2 dimensional silicon memory binary memory will not manage itself. And you can't just assume that on that vast plane a byte will stop and start where you want it to. You have to know. Isn't that how the bad guys do it? Knowing where your byte is AFTER you ASSUME it its somewhere else?

Re:

[phantomfive]

A lot of programmers don't understand how 2 dimensional silicon memory binary memory works. You can't find enough programmers who do understand it, so you hire people who don't.

Instead of training them, you just give them Rust or Python and don't worry about it.

Re:

[SirSlud]

could you speak on this more? I would love some more of this word salad

Re:

[drnb]

could you speak on this more? I would love some more of this word salad

I think it's a Star Trek: The Next Generation reference, the Android "Data" explaining a problem to someone. :-)

Biomemory is the future.

[unfriendlyLLM]

With some minor modifications those battery farms in the matrix can also become memory banks.....

Why are we primarily targeting memory issues?

[lsllll]

It seems to me from CVE breakdown by type [cvedetails.com] that memory issues result in a somewhat small subset of total CVEs. Where is this concerted effort of making more languages police the programmers' use of memory coming from? Sees like XSS is much more of a culprit in regard to vulnerabilities, despite modern browsers' locking down of XSS interactions. Is it because the languages are trying to adapt to corporations seeking cheaper and cheaper programmers?

Re:Why are we primarily targeting memory issues?

[FeelGood314]

Memory issues can be found by noobs running scans on executables. The real bugs are in people completely missing what the attack is and having no mitigations at all against the attack. If you want secure software:
1: list out what you are protecting - a secret, authentication for something else to do something, control to something
2: list out what your opponents are, their motivation, their resources, their access - is it a script kiddy, a foreign government, do they have physical access
3: list what the attacks could be - physically damaging your device, bypassing it, signal blocking, replaying an old command...
4: come up with mitigations to all the attacks. ***All mitigations must trace back to an attack ****
5: evaluate your system. How complicated is it? Could the things you are protecting be individually protected or is everything protected at once? Do your mitigations actually mitigate the attacks they are mapped to? Have you missed any attacks and can you accept those vulnerabilities? Go back to how complicated your system is. If you can't explain it, then no single person can take ownership of the security and you will have attacks with no mitigations.

Re:

[ArmoredDragon]

The real bugs are in people completely missing what the attack is and having no mitigations at all against the attack.

...

4: come up with mitigations to all the attacks. ***All mitigations must trace back to an attack ****

In that case, what are all of your mitigations against unchecked bounds, use after free, double free, dereferencing invalid pointers, and their related cousins, dirty reads, and dirty writes?

Re: Why are we primarily targeting memory issues?

[viperidaenz]

Xss is language agnostic.
I dont see how the two are comparable in the context of compilers and languages

Re:

[lsllll]

I'm aware of that. What I was alluding to was that perhaps fixing buffer overrun and such issues via changes to languages is an effort to make programming more fool-proof and that it may result in possible lower wages for better programmers by giving sub-par programmers the tools to compete on a more level playing field.
 

Re:

[Samantha Wright]

Cross-site scripting attacks do not generally involve issues that the C++ designers can address. They are, at best, logic errors on the part of browser programmers who didn't implement their APIs according to their own specs.

Now, disregarding XSS, the total number of overflow and memory corruption bugs exceeds all the others combined: 37695 vs 33290 in the years 2014 to 2024—those two categories add up to 38% of all CVEs in the time period. That's a lot of wasted labor brought on by a reckless corne

Re:

[arglebargle_xiv]

Because it's an itch we can scratch. OK, everyone wants you to scratch differently and sometimes it just makes the itch worse, but it's still easier than dealing with any of the other, more significant, problems.

malloc_safe_safer_safeforrealthistime()

[Pseudonymous Powers]

I think I remember a similar proposal from ten years ago. Didn't somebody advocate around then for a bunch of functions whose names were suffixed with "_safe"?

Re:

[youn]

let's call this _safe_safe_for_realzies_this_time_i_swear :p

this seems more involved and I am glad some are getting the message, potentially can be a good thing

A borrow checker for C++

[LindleyF]

Is a legitimately good idea. Anything that moves errors from runtime to compile time is beneficial.

Re:

[caseih]

Definitely. That and other compile-time checks including checking that all enums are handled properly. Circle C++ does all of this. Getting the concepts developed in Circle into the core C++ standard will be highly beneficial. C++ is still complex and crufty, but you can not use the old, complicated stuff in favor of the new safe constructs and syntax. No one should be passing raw pointers around. std:: has contained some powerful reference-counting smart pointers for years now that were a step in the r

Re: A borrow checker for C++

[LindleyF]

Shared_ptr is very useful when you need it, but you usually don't need it. Unique_ptr is essential, though. But I disagree that raw ptrs should never be used. They do have a place. But *owning* raw ptrs should never happen. If you see a raw ptr, you should be able to assume it is unowned.

Re:

[chuckugly]

This. If the committee would figure out optional references we would have a lot fewer use cases for raw pointers as well.

Re:

[ArmoredDragon]

It feels like they're trying to reinvent rust and just slap the C++ moniker on it so they can say they didn't have to learn a new language.

Besides, the biggest gripe most of them have against rust to begin with IS the borrow checker, and this is despite the fact that they like to pat themselves on the back about how good at RAII they are, and then violate its principles anyways.

Circle C++ does all of this.

One thing I haven't seen any interest in from C++ developers is using optional types and result types. Instead they seem to have a

Re:

[ArmoredDragon]

Just to clarify: I am aware of Circle's 'Choice' type.

Re: A borrow checker for C++

[LindleyF]

I'm not a fan of exceptions in C++. They basically are invisible control flow and that's hard to reason about. absl::StatusOr is a nice pattern that you might consider "choice."

Re:

[starworks5]

It feels like Rust is taking what used to be the domain of a test framework, shoving it into the compiler, and then slapping the "memory safety" moniker on it, and trying to define every other language as "memory unsafe".

look up the definition of a compiler:
https://en.wikipedia.org/wiki/Compiler
"In computing, a compiler is a computer program that translates computer code written in one programming language (the source language) into another language (the target language)."

look up the definition of a softwar

I agree 100%

[Zolmarchus]

The one thing that will make C++ easier to learn and understand, more welcoming, more straightforward, and will eliminate fragmentation and baggage, is just one more extension.

Re:

[youn]

lol, since you seem to like extensions, I extend to you my sympathy :p

Legitimately good idea.

[engineer37]

I'm not saying this is the end all and be all solution to memory safety. However, this is still a good step in an interesting direction. Why not try to retrofit memory safety into C++? This kinda makes sense conceptually. If there are developers who insist on C++, then it makes sense to attempt to develop a memory safe version.

Even Rust has unsafe blocks where you can use unsafe features, so it's actually not as much of a stretch to imagine a memory safe version of C++ as you'd think. We already have examples of memory safe languages that are C++-like or C++-inspired (Java, C#), so I think it's actually reasonable to try to adopt the features of memory safe languages. C++ is known for having everything and the kitchen sink, so why not adopt both Rust-like memory safety options as well as garbage collection, and let users choose?

These are just ideas I'm throwing out here, my main message is that this is that I like this line of thinking, and I think it could be a step in the right direction. Sure, it has a lot of issues that still need to be addressed (like how do you enforce safety for users who want to enforce it?), but I just feel like there's some good core thinking behind this.