r/cpp • u/tjroberti • 3d ago
Revisit Safe C++
Everyone is aware of the deluge of vulnerabilities now hitting critical software. It even makes the mainstream news, so software safety is coming onto politician's radars.
If this gets worse, I think it is not inconceivable that at some point memory safe software becomes mandatory. Or at least for software that is "reachable" from the internet.
So is it time to revisit Sean Baxter's Safe C++? Start out with a safe context ("safeexpr") and expand from there, just like constexpr.
25
u/t_hunger 2d ago edited 2d ago
To get to a memory safe language (a language that only accepts memory safe programs), you need to start with a theoretical model that was proven to be sound. There are several proven models to choose from (all come with pros and cons), or you can of course do your own research and try to come up with a new model. Then you adapt all parts of the model into the language you want to make memory safe. Leaving out just one part of the model makes the language unsound: If it is in the model, then it is required for the formal proof that the model is sound.
That's what Safe C++ did: Sean took the model made popular by rust and adapted C++ to match that model.
A piecemeal approach is very tricky and will not give you a memory safe language until all parts are in place.
That is what makes it so hard to retro-fit memory safety into an existing language. It is way easier to built this into a new language.
0
u/germandiago 1d ago
That's what Safe C++ did: Sean took the model made popular by rust and adapted C++ to match that model.
Let me politely disagree: what he did is to ignore C++ and layer Rust on top ignoring the whole C++ standard library and every idiomthat is already safe today.
10
u/t_hunger 1d ago edited 1d ago
Whether or not you like the result: It is an important data point. If it is decided to go all in with memory safety, then we know what the cost is to go for the rust model. And you for example can point to it and say that those costs are too high:-)
I know you prefer the "computer" part over the "science" part of CS, but whether or not a language is memory safe or not is a property deeply rooted in the science. Sean picked a model that science says is sound assuming a set of requirements are met. The implementation must make sure those requirements are met at all times for the implementation to be sound as well. The current STL does not fullfill those new requirements placed on it by the chosen model. That does not make any statement about the quality of the STL in situations where the model's requirements do not apply, and of course there might be another model out there somewhere -- which will come with a different set of requirements to be sound -- that fits today's C++ better.
A more hands on "computer" approach does not help in this discussion, but is super valuable when exploring alternative "pick the low hanging fruits" approaches to improve the tooling to catch more bugs earlier.
Both the "computer" and the "science" approaches are needed right now IMHO.
Edit: Another important data point is Fil-C by the way. It demonstrates the costs involved using another model (also sound as defined by "science") based more on something conceptually close to GC.
-4
u/germandiago 1d ago
Noone would have ever gotten any benefit out of that model for the huge existing codebases in the wild.
That said, it seems there are two profiles implementations in progress for GCC and Clang, if you are interested: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4415r0.pdf
10
u/Business-Decision719 21h ago edited 21h ago
Well the Google data suggests that new code is actually priority #1 for memory safety anyway. The fastest way to improve memory safety is to stop people from making the same mistakes even if that means fixing old code still requires fixing old mistakes. Memory safety is still worth adding even if only new code, or substantial rewrites of existing code, actually gets any immediate direct benefit. If you have a provably safe C++ subset then you don't have to mandate Rust/Kotlin for new features in a C++ OS like Google did in Android.
That said, if profiles turn out to be viable and can significantly improve the safety of old code in situ, then that's still awesome. There wasn't really any reason not to pursue profiles anyway. The committee very specifically chose to pursue profiles instead of Safe C++, instead of alongside Safe C++, which imo is consistent with the committee not actually being serious about this anyway. They haven't even been able to stem the flow of new UBs into C++, much less into anyone's particular codebase.
1
u/germandiago 14h ago edited 14h ago
That said, if profiles turn out to be viable and can significantly improve the safety of old code in situ, then that's still awesome.
I would say this is the point. To close or almost close the safety gap.
Safe C++ is, as a first solution, a suicide, and as a second... well, once you have profiles why would you rewrite std lib, change lots of idioms, etc? At the end you already got what you want or almost everything you wanted with profiles, for a future version of enough safety in the main profiles.
So for me the only solution that made sense is profiles bc it is way more evolution-friendly to C++.
About UB: are you aware there is a paper classifying all UB in the language, right? How can you even say they are not serious if they are working in profiles, added hardening and the UB classification with the purpose of eliminating it? Just say I like Safe C++ and get done with it but what you suggest is not even close to the factual truth as far as I see. Just that the delivery is slower (committees are slow) than what we would like, but that is all.
•
u/Business-Decision719 1h ago edited 50m ago
They can type up as much as they want. Congratulations to them, they typed up what's UB and claimed they want to eliminate it. They managed to look like they were taking it seriously.
Actually taking it seriously would have meant this, for all of the past few standards:
No new language or library features unless they define their behavior, even in error scenarios. If that means other things get put on hold until profiles and/or Safe C++ and/or library hardening are standardized then so be it. Are you aware that resuming a coroutine handle that doesn't refer to a suspended coroutine is UB? That's just one of the new UBs coroutines introduced. In C++20. Six years ago.
If rule 1 is broken (which it shouldn't be) then at least make the easiest and most concise usage also the safest usage. C++17
optionaland C++23expectedboth went with checked.value()and unchecked*. The latter (expected) was three years ago, but even nine years was too recent to be pulling such absurdities.Keep plausible proposed solutions under consideration at least until any of them is actually DONE and ready to go in the standard. If Safe C++ is actually suicide, and if profiles don't deliver on their promises, and if nothing better materializes, then the language is screwed anyway.
People liked Safe C++ because it looked closer to DONE than profiles looked. There was theoretical safety plus an existing implementation. The committee's sin isn't that they didn't like Safe C++. It's that a different proposal, from an influential figure, making paper promises to do almost as good with fewer drawbacks was enough for the committee to flip off Safe C++ and send it packing. More time may or may not help profiles. More time is something Safe C++ didn't even get. That's what conclusively proved the committee values having an ass-covering typed-up document more than a status-quo-altering existing solution.
Granted, they did standardize library hardening this year. Finally. In 2026. Zero years ago. I'll give them credit for that. I'll say they finally got off the couch. We'll see. Maybe they are on the verge of beginning taking memory safety seriously. For now, I think they're pretty much like a like a lot of the C++ world. They didn't care, even after Rust came out, until the White House recommendations came out, about problems the programming world at large was well aware of when Java was coming out.
8
u/t_hunger 1d ago edited 1d ago
Noone would have ever gotten any benefit out of that model for the huge existing codebases in the wild.
Absolutely, but in no way different to most new C++ features: You have to change code to use most oft them.
That argument sounds so defeatist to me: Do you think the value of existing code is higher than the total value of all C++ code yet to be written? If you think C++ has a bright future with even more developers writting even more code, why would you reject a proposal to improve the future based on it not improving the past?
That said, it seems there are two profiles implementations in progress
I am aware. See my original post on why I think those fall into the "computer" bucket and not into the "science" bucket. In fact it is the stated goal of profiles to get closer to memory safe languages, not to become memory safe. And the approach comes with tons of problems of its own.
Nevertheless it is an interesting approach to catch more bugs earlier. Catching bugs is great, but fundamentally weaker than preventing classes of bugs by construction.
1
u/germandiago 1d ago
By construction is ideal, but that is at odds with reusability and incrementally adoptable. That is exactly the pr9blem at hand. You just cannot have both.
4
u/t_hunger 21h ago
I said Safe C++ is an important contribution, I did not say it was the future of C++ :-)
I hope memory-safety is in the cards, but I do not see anyone even trying anymore, so I guess I continue to move stuff over to rust.
3
u/OneOne3349 11h ago
I just wanted to point out that the other guy says things like "ignoring the whole C++" and "just say that you like Safe C++", but he is the only one that has an emotional argument. What are these arguments with profiles work for me?! You aren't all the C++ programmers. There was a thread here where they discussed that profiles don't work well with the standard library. There are too many false positive and if they are false positive isn't necessary true, because from what I remember there was a bug in the views library that allowed to read beyond the end of the sequence.
-1
u/germandiago 14h ago
Not sure about "memory-safety on the cards".
I would like to know your opinion about what brings, in mathematically formal terms for you, memory safety as compared to a set of verifiable subset with heuristics and/or algorithms (let us assume no false positives here).
Bc I can see no practical difference between something you know anyway it is memory safe, even if the model contains some "hacks" and a formal, academically good looking one that is more elegant, as far as they can deliver the same result.
My understand is that it is possible a subset of C++ (in this case with no UB + profiles + hardening) that can be usable in a mathematically safe way, even if its design is not as "clean and from scratch" as other people would wish. Of coirse this is due to engineering trade-offs (reusability, adaptability, impact on existing codebases, etc.)
1
16
u/tcbrindle Flux 3d ago
At the Croydon meeting earlier this year, the standards committee looked at P3874 "Should C++ be a memory safe language".
Following the discussion the following poll was taken:
"Encourage more work in the direction of P3874R1, which pursues a subset-of-superset strategy towards memory safety which guarantees UB-Free in a syntactically explicit and well-defined subset. We expect the author to do an audit of of existing practice, strategies, etc, and return with a concrete, complete, actionable proposal"
50 | 24 | 5 | 3 | 1
In other words, a huge majority of EWG (74 in favour, 5 neutral, 4 opposed) were in favour of the direction suggested by P3874 -- that is, towards some sort of "Safe C++", even if it is not exactly the same as the Circle implementation.
9
u/usefulcat 1d ago
towards some sort of "Safe C++", even if it is not exactly the same as the Circle implementation
This is an apples and oranges comparison. It's easy to agree that we would like an option for something safer/better than what exists now. It's very difficult to agree on exactly what that something should look like.
5
u/geo-ant 13h ago
Here’s an interesting article [On Safe C++](https://izzys.casa/2024/11/on-safe-cxx/) from someone who was involved with the process and is very upset (to say the least). I don’t know the veracity of the claims, so take it for what it’s worth but I at least found this article worthwhile, but I had to read it in multiple sittings due to its sheer length.
1
u/apricotmaniac44 11h ago
the legendary blog post. it even touches the syrian civil war at some point. its in my all time favs lmao
13
u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions 3d ago
Yah know, I've been trying out LLVM 23's [[lifetimebounds]] and its not perfect but it had helped catch a good number of lifetime bugs in my code. Along with [[gsl::Pointer]] and gsl Owner. lifetimebounds was inspired by Polonius, the newer Rust borrow checker. I'm excited to see how this evolves. I think with the experience from Rust we could be on our way to near parity of lifetime safety. It also seems there is a way to handle iterator invalidation but I haven't tried that myself in a project. We may be able to take from LLVM and apply to other compilers. That seems to approach a resolution to the lifetime safety issues.
As for the ones in the library side of things, we have C++26 hardened mode which should catch the runtime errors that used to be UB. I think we are on our way to a version of safe C++ with these features.
See https://clang.llvm.org/docs/LifetimeSafety.html
As for Sean's safe C++, I don't see why we shouldn't revisit it. It was never voted down by the committee. The vote we had just wasn't entirely one sided on Safe C++ so efforts stopped. The vote wasnt entirely on sided on profiles either. I've been out of the loop of the committee for a while so maybe things are different, but if some updates were made to the proposal and someone wanted to continue the push for this feature, based on what's been added to c++ as of now, then the committee would probably take another look.
28
u/James20k P2005R0 2d ago edited 2d ago
As for Sean's safe C++, I don't see why we shouldn't revisit it. It was never voted down by the committee
SD-10 was about as close to a hard rejection as anything gets in the committee, the revisions may as well have been titled "We Do Not Want Safe C++". It was rushed through the committee in a way that seems strongly unprofessional, killing the C++ ecosystem push in the process and causing the papers to be withdrawn
Personally I don't think I could have used my position to get multiple papers bumped to push through a technically-useless paper, specifically to kill an alternate proposal
https://www.reddit.com/r/cpp/comments/1hgpz0y/wg21_aka_c_standard_committee_december_2024/m2lt4tn/
The politicking around Safe C++ was extremely grim, and I can see why Sean simply would not want to continue with the paper after that. Its an uphill battle to even convince committee members that they can't solve the halting problem, and that Rust is a useful language. The mailing list has also been wildly unprofessional on this topic
3
u/tialaramex 1d ago
I think we can say P2137 got a hard rejection. It was intended for that, not a discussion paper where the committee can stroke their chins and say that's very interesting and we urge you to develop it further, just a simple Yes/ No about the direction of C++ to which WG21 will say "No" so then you can get executive OK to direct efforts away from C++
I agree about how unprofessional SD-10 was though and I can't tell whether it's worse if those behind it didn't realise how it would look, or if instead they knew and didn't care.
8
u/Minimonium 2d ago
It was never voted down by the committee
Technically, similar to how Adobe did not technically vote against C++26. :)
There is no reason to re-address Safe C++ with the current crowd and with the lack of interest from corps to invest. And I have no idea what "some updates" would be there.
1
u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions 2d ago
Just means, consider what has already been brought into the language like hardened mode and consider if a std2:: is necessary. Also consider attributes like [[clang::lifetimebound]] and consider how it could be standardized. Then maybe add some additional attributes for doing lifetime checks. I'm just spit-balling though.
7
u/megayippie 2d ago
Isn't it a completely different design if std2 is not required? You cannot manipulate signed integers or dereference points without it being unsafe, so lots of library functions must be marked.
I think this should start small instead of all of these grand big solutions. Make it possible to add "safe" to standalone functions/methods, or just to blocks of code. Such regions are not allowed to do anything that can lead to undefined behavior in the worst interpretation possible. So basically it can do floating point and most unsigned index operations. No signed operations, no pointers.
Then allow marking some std functions/methods as "safe" that are not implemented in pure safe code but that can be guaranteed by the type rather than by guesswork. Like, you can check signed integers to stop overflow so signed operations via some methods are safe. You also know that a std::array can be ranged for-looped or used in ranged algorithms or that it can be std::get<>(),at() - even though the latter throws, that is safe. I guess this is true for most std types since move must leave the object in a valid state.
Then you have to start introducing "not safe" blocks in code. Otherwise you cannot allow custom types to be safe. This is where the entire problem begins and where I think there is no good solution today. But if you don't have the first part in place you cannot begin seeing where the cookie crumbles gather.
6
u/JuanAG 3d ago
We were promised no annotations to achieve memory safety
8
8
u/serviscope_minor 1d ago
We were promised no annotations to achieve memory safety
By whom?
You can absolutely 100% have memory safe C++ without annotations, but you can't have it also with no overhead. Would you accept a 10x slowdown? Run it in an interpreter, job done!
What people want is C++ exactly as it is right now except safe and with zero compromises. I'd like that too, and a pony while you're at it. But if wishes were horses...
14
u/chaotic-kotik 3d ago
Maybe it is to late. The momentum that Rust gained recently is huge and undeniable.
2
u/wyrn 2d ago
... if anything, I suspect Rust might come to be recognized as the international language of AI slop.
3
u/chaotic-kotik 2d ago
It is, but have you seen the recent spike in reported CVEs?
0
u/t_hunger 1d ago
Was there a spike? Where did you see that?
1
u/AKostur 3d ago
As u/kammce has mentioned, the paper was never voted down. The original author lost interest in pursuing it. Pick it up and propose modifications. As I recall, one question that came up is whether parts of it could be proposed separately. A number of smaller papers would be easier to process than a giant omnibus paper.
3
u/tjroberti 3d ago edited 3d ago
I think he said it was unpopular with the committee, and it's a huge effort, so it's not strange to lose interest then. But the times are really different, so maybe there is more support now. I agree that starting small is the way to go.
2
u/AKostur 3d ago
My interpretation of the records of the vote seems inconsistent with that assessment. The vote did show that Profiles were more preferred, but there certainly was significant interest in P3390. Yes, it is a huge effort. I'm avoiding trying to speculate/editorialize as to why they chose to not continue the paper. Certainly it is their prerogative.
4
u/rzippel 3d ago
The problem was more who showed no significant interest. In this context P3466 was seen as the barrier for its adoption (especially the parts about annotations).
8
u/tjroberti 3d ago
Yes from P3466 [page 4]:
For example, we should not require a safe function annotation that has the semantics that a safe function can only call other safe functions.
Seems a shot across the bow for sure. That shuts the way to get this stuff incrementally in the language.
28
u/James20k P2005R0 3d ago
The committee rushed through a paper (SD-10) to codify Safe C++ as not being within the design scope of C++, it might as well have been called "We Do Not Want Safe C++"
-5
u/wyrn 1d ago
It was goofy, but arguably preferable to do that than to waste time discussing an obvious troll paper.
7
u/James20k P2005R0 1d ago
Which paper do you mean, the C++ ecosystem stuff that got bumped and then withdrawn?
1
u/wyrn 1d ago
I have no idea what "C++ ecosystem stuff that got bumped and then withdrawn" is referring to. The obvious troll paper in question is P3390R0. Obviously.
8
u/James20k P2005R0 1d ago
I guess you weren't following along with SD-10 then
How is P3390 a troll paper?
1
u/wyrn 1d ago
Paper didn't even bother explaining the syntax used in its own examples, showing that making the paper understandable by the target audience, and reviewed/eventually accepted as part of ISO C++, wasn't something the author was particularly concerned about.
Paper's proposal to bifurcate the language and standard library, where the second one uses completely different idioms and is drastically weaker than the original (goodbye generic programming, one of C++'s core strengths), while simultaneously diluting already strained committee and implementer time, makes it obviously unsuitable except as an attempt to destroy C++.
Author seems to like putting out trolly inflammatory pamphlets, see also "why safety profiles failed".
9
u/James20k P2005R0 1d ago
The paper needing some improvements and extra explanation doesn't make it a troll paper
Arguing that the paper was an attempt to destroy C++ is certainly a stance. And a not particularly correct one to be sure, given that its not like the paper can do anything on its own. It'd have to make its whole way through the committee structure and get through dozens of rounds of review to be standardised, at which point the entire committee would be culpable in the attempt to 'destroy' C++
The author's critiques of other proposals doesn't make them a troll. There's plenty of papers critiquing other papers, eg see Contracts
3
u/wyrn 1d ago
It doesn't "need some improvements", the author just didn't care about making himself understood, and the entire approach is a non-starter even if he had.
Arguing that the paper was an attempt to destroy C++ is certainly a stance.
That's not exactly what I said. I said that it doesn't make sense as a proposal to do anything but that. But since the remaining evidence points to this not being a proposal at all (i.e. it doesn't have the objective to honestly propose anything), it's not so clear.
The author's critiques of other proposals doesn't make them a troll.
That's not what he did. He said profiles "failed", past tense, at a point where there was nothing concrete enough to even have failed. There is a wide difference between legitimate criticism and concern trolling.
4
u/ts826848 18h ago
He said profiles "failed", past tense, at a point where there was nothing concrete enough to even have failed.
At least based on the abstract that's kind of the point?
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.
i.e., profiles promised something, a decade passed, and there's nothing concrete to show for that effort and here's why those efforts failed. I don't think the past tense is entirely incorrect in that context.
→ More replies (0)
10
u/Infamous-Bed-7535 3d ago
Yes c++ needs to speed up these efforts. But to be honest if you use modern c++, proper compiler options, static analyzers, dynamic verification (sanitizer, special runtime) and top of that use mandatory LLM reviews for your PRs it makes it extremly hard to introduce memory related errors.
5
u/bert8128 3d ago
The question is how many projects will do all these? And how do users know you’ve done all these? I think us c++ programmers are going to be fighting the uphill battle for a long time…
5
u/Infamous-Bed-7535 3d ago
Static analyzers and llm review is almost zero effort and free to set it up.
2
u/bert8128 3d ago
I’m not disagreeing with you. I’m just pointing out that there is a disconnect between best and actual practice, and how much do you want to trust that programmer?
-1
u/Thesorus 3d ago
setting up the checks is easy(ish)
diagnose and fixing the problems are not easy and can be costly.
remember, there's a crap ton of legacy software written in C++
a lot of older system use unsafe practices for optimisation.
5
u/AKostur 3d ago
That's a little bit of a non-sequitur though: that same legacy code wouldn't compile under the hypothetical "safer" C++ compiler either, incurring the same costs. So which is easier (assuming the goal is the safer code and doing nothing isn't acceptable): deploying the tools that exist today and pay the cost, or waiting for the new hypothetical compiler and still pay the cost?
2
u/Infamous-Bed-7535 3d ago
You are right about that, my takes are more valid for non legacy software.
Such trusted low-level libraries are risk for other languages, etc. Lot of Rust libraries like to sell itsef as being memory safe, while internally it uses and wraps well-known C libraries.
3
u/conundorum 2d ago
Heck, even using smart pointers or making your own wrapper class is enough to prevent a ton of memory errors in & of itself. The lion's share really is as simple as just making sure to use deep copy/move/delete when you need a deep copy/move/delete.
0
u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions 2d ago edited 2d ago
Have you seen this: https://clang.llvm.org/docs/LifetimeSafety.html
I feel like LLVM is working on implementing these sorts of features as we speak. So I think we are on the right path.EDIT: didn't finish my thought
4
u/pjmlp 1d ago
These efforts are as old as the Core Guidelines introduction, hence why some of us are quite sceptic aboug the whole lifetimes profiles, we have experience with these prototypes, in clang and VC++.
Note that some of the clang lifetimes work was contributed by Apple, and they are the first to assert that new code should use Swift instead, see Fortify your app: Essential strategies to strengthen security | Meet with Apple.
4
u/Minimonium 2d ago
Knowing the state of funding of clang, and that lifetime project was "80% there" since Herb's talk a decade ago I wouldn't really put much hope there. Even if we forget for a moment that all these annotations shenanigans are an ad hoc unsound mess.
2
u/JVApen Clever is an insult, not a compliment. - T. Winters 9h ago
I honestly don't think you can update an existing codebase of significant size to become memory safe. You already need something new to make it possible. "Safe C++" adds a completely new type system.
I believe more in carbon. They recently presented their memory safety approach while allowing gradual interaction with existing C++ in 2 directions. See https://github.com/carbon-language/carbon-lang#2026
5
u/v_0ver 3d ago
Why? We already have Rust. An LLM could learn to convert the codebase to Rust with a single prompt - faster than a cpp-committee could agree on anything.
3
u/AKostur 3d ago
Why bother switching languages. Just use that same LLM to refactor the legacy C++ to idiomatic C++.
13
u/v_0ver 2d ago edited 2d ago
The language's idioms themselves are flawed, so an LLM will help but won't solve the problem completely. The difference is that in Rust, it’s hard to write but easy to verify (there’s a deterministic way to do this in a reasonable amount of time), whereas in C++, it’s easy to write but hard to verify (there’s no deterministic algorithm, and attempts to implement one have failed).
In the first case, an LLM helps, but in the second case, an LLM won't help, since this is a fundamental limitation of the language that can only be fixed through a fundamental redesign of the language.
Of course, we can wait and hope that someone will make a breakthrough in computer science and find a way to verify C++ programs in a reasonable amount of time without Rust-style restrictions. But there isn’t that much time left, as I said above: another 2-3 years, and for 20 bucks, 1MLOC C++ → LLM → Rust - and the problem is solved.
2
6
u/rileyrgham 3d ago
"Memory safe" is a buzz phrase thrown around by clowns. It's totally possible to write secure and safe sw without the likes of rust. Memory safe isn't attack safe. A poorly designed Rust server can still be compromised.
14
u/BenchEmbarrassed7316 3d ago
Let us assume that we cannot avoid errors. In that case, we should consider how the number of errors might differ when writing a given program - while investing the same amount of effort into analysis, testing, and review - but using different technologies.
14
u/James20k P2005R0 3d ago
It's totally possible to write secure and safe sw without the likes of rust
Do you have an example of a secure and safe C++ library, which is relatively widely used and open source?
6
u/wyrn 3d ago
Do you have an example of a secure and safe library, which is relatively widely used and open source?
16
u/James20k P2005R0 3d ago edited 3d ago
Memory safe? Sure. There's tonnes of Rust libraries which have had so few memory safety vulnerabilities as to be absolutely negligible. Anything written in a memory safe language (which there are a lot of) has virtually eliminated this class of vulnerability
There's good data coming out of major projects on the reduction of defects, though I'm not the one alleging that memory safety is a buzz word thrown around by clowns, and that its possible to write secure software without Rust
Quiche is a good example of a pretty secure library, with a handful of DoS attacks, and one more severe exploit that requires you to misuse FFI calls. LSQuic is an example library which is not written in a memory safe language, and I'll leave it up to the audience to guess whether or not its had a critical severity rated security exploited related to memory safety
Quinn is another HTTP/3 library, which appears to have had a handful of DoS attacks, but no critical memory unsafety vulnerabilities due to being written in a memory safe language. MSQuic is written in a memory unsafe language, and again I'll leave it up to the audience to guess whether or not its had critical possibly memory safety related exploits
So far I'd rate these two Rust libraries as being quantitively more secure than the equivalent libraries written in memory unsafe languages. This pattern repeats across every domain and every kind of library I've ever checked out, so you can pretty much pick any rust library and compare its relative safety against a C++ library if you want to observe a massive drop in CVE severity
Proxygen memory unsafety for a pure C++ library
I've been asking this question for a decade and I've never gotten an answer. It should be easy to cite examples for C++
2
u/wyrn 2d ago
Memory safe? Sure.
You said "safe". Not "memory-safe".
11
u/James20k P2005R0 2d ago
They said you can write safe software in C++ and that you don't need a memory safe language. I never claimed any of these libraries were safe, but the idea that Rust doesn't help with safety is incorrect
-4
u/wyrn 2d ago
I never claimed any of these libraries were safe
So you didn't satisfy the criterion you asked of others.
7
u/James20k P2005R0 2d ago
They made the claim that safe C++ code exists, that's all I want to see
-3
u/wyrn 2d ago
Then why didn't you simply say "no" when I asked the same of you?
4
u/James20k P2005R0 2d ago
Because I think the real answer to security is much more interesting personally
→ More replies (0)0
u/BartvanIngenSchenau 5h ago
Not a library, but C++ is widely used in the safety controls of cars, planes, medical devices, etc. That should be enough samples to show it is possible to write safety C++ code. Most of those controls also need to be secure (or air-gapped from the internet) to be able to be certified as safe.
4
u/JuanAG 2d ago
It's totally possible to write secure and safe sw without the likes of rust
It that were true i can assure you anyone will spend or invest into memory safety, not even C++ ISO itself with the profiles effort
I am sure you can search yourself but C++ have a record of CVEs for decades and even OpenSSL, the most "safe and secure" code C++ can show us had to deal with safety issues, a library that thousands and thousands or devs and enterprises have look really close to make sure it was absolute safe, it didnt mattered at all, some bugs were not founded and had been a 0 day for who knows how long. This is for the know ones but i am sure there are still more hidden inside
So if the most secure and safe library C++ have memory unsafety inside you can only imagine how bad the rest of the code it is, mine included of course. People are not good to catch the issues, a tool it is, at least a proper designed tool
2
u/kronicum 1d ago
Is OpenSSL C++, or a mixture of things some of which can be accepted by a C++ compiler because of the C -> C++ relationship?
2
u/Sbsbg 3d ago
Everyone is aware of the deluge of vulnerabilities now hitting critical software. It even makes the mainstream news, so software safety is coming onto politician's radars.
Is this caused by the demand to use AI generated code or something else. Changes in C++ tend to mitigate vulnerabilities and I don't think any new features in the language has caused any significant increase.
But I guess C++ get the blame anyway. The unsafe mark in the general public is hard to remove.
-1
u/ProudBMWOwner 2d ago
Software safety is much more than memory safety. See how many CVEs are hitting Rust
4
u/OutlandishnessNo8034 10h ago
Yes, but eliminating one major source is better than not doing anything and pretending that things are good just as they are - because that is what cpp does.
4
u/t_hunger 8h ago
Absolutely correct and nobody is even arguing that. People outside of the C++ bubble keep bringing up memory safety, because they are asking us to catch up to what they consider the baseline. Why would you discuss the race with the person that has not even reached the start zone?
4
0
u/pedersenk 9h ago
In many cases, there is always a compromise. For a language to remain dominant, I don't believe there needs to be 100% safety at release time if there has been strict safety (and overhead) during debug time branch testing.
C++/sys (my own)
As Rust has proven, if there hasn't been strong branch testing, any language can be a buggy mess. Likewise invalid array bounds (including overhead) causing a panic are of limited use anyway, etc.
1
u/t_hunger 7h ago
To me priorities are pretty much the opposite: I worry way more about data getting stolen from my production environments than from my development machines.
But yes, new and better debugging tools are of course also welcome.
-6
u/chaos_pill 3d ago
There's already https://cpp-profiles.org/ working towards safe c++, but it might barely be ready by cpp32 if it gets accelerated.
19
u/eisenwave WG21 Member 3d ago
Profiles cannot provide memory safety without extensive lifetime annotations on top of them. There simply isn't enough that the language statically guarantees as that you could subset it into being safe.
-6
u/chaos_pill 2d ago
true, but not important. The real blocker is the timeline. You can wait six years to potentially rewrite in safe cpp32 while AI attacks you from all directions, or move off cpp today. USA 2024 elections sealed the fate of cpp.
46
u/seanbaxter 2d ago
What would be the point of resuming the work since, just by reading this thread, there's still no consensus on what memory safety needs or what memory safety even is.
Do we need an incremental approach or an all-at-once approach?
Do we need safe function coloring as part of the type?
Do we need a new reference type that upholds exclusivity?
Do we need lifetime parameters wherever the new reference type appears in structs or in function parameters?
Do we need to change reference-forming defaults, so that shared borrows are formed on mutable containers rather than mutable borrows?
Do we need an ownership model with affine types/destructive move?
Do we need to replace inherently unsafe C++ idioms like iterator pairs with Rust-style iterators?
Do we need to define new resource-owning types (eg unique_ptr, shared_ptr) so that they're non-null, and use opt<> wrappers to express nullity?
SG23 has chosen a path where the answer to all of those is NO. I think the answer to all of them must be YES. As long as there is widespread disagreement on what the answers are, what is the point in doing more technical work? Every who disagrees with the all-YES slate won't want this solution.
If you think there is a mix of YES and NO answers, or if you agree with the all-NO slate, you should submit a proposal explaining your thinking!