C and C++ are kind of losing out to Rust right now. Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just an example): https://ladybird.org/newsletter/2026-05-31/ "The HTML parser is now written in Rust" "The Rust parser is also about 10% faster than the C++ version it replaced," I am not saying this is a systematic analysis by far, but Rust is pushing into domains…
How memory safety CVEs differ between Rust and C/C++
31–40 of 270 posts
Re: How memory safety CVEs differ between Rust and C/C++
#32Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if there is UB in one of the libraries used as a dependency by the library you are using. Nor if there is UB in the Rust standard library. Which has happened many times, since the Rust standard library is full of unsafe. Rust also requires libraries to be safe reg…
If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).
Re: How memory safety CVEs differ between Rust and C/C++
#33Earlier quoted context omitted.
If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).
[flagged]
Re: How memory safety CVEs differ between Rust and C/C++
#34Is it only me that would have expected curl_getenv() to have an assert that it's argument isn't NULL? I know this doesn't stop runtime problems in release builds, but i'd have thought this sort of simple precondition check would help users find problems in their library useage. It's not going to stop you passing a non-terminated string, or other such invalid input though, which is I guess more the point, that it's to…
Re: How memory safety CVEs differ between Rust and C/C++
#35Re: How memory safety CVEs differ between Rust and C/C++
#36C and C++ are kind of losing out to Rust right now. Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just an example): https://ladybird.org/newsletter/2026-05-31/ "The HTML parser is now written in Rust" "The Rust parser is also about 10% faster than the C++ version it replaced," I am not saying this is a systematic analysis by far, but Rust is pushing into domains…
[dead]
I don't think its fair to attribute it to lack of skills or bad intent, unless there's some proof to any of it.
Re: How memory safety CVEs differ between Rust and C/C++
#37Earlier quoted context omitted.
[dead]
Knowing little about cpp modules and nothing about Gabriel Dos Reis, I expect a more design-by-committee type explanation for the result: the module system was probably a victim of having to be backwards compatible, abi stable, idiomatic, zero cost abstraction, be compatible with all weird cpp features, not hurt compile time, etc etc etc I don't think its fair to attribute it to lack of skills or bad intent, unless t…
Re: How memory safety CVEs differ between Rust and C/C++
#38Earlier quoted context omitted.
> Nor if one of the soundness holes in the Rust programming language itself is encountered. imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.
You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.
Re: How memory safety CVEs differ between Rust and C/C++
#39C and C++ are kind of losing out to Rust right now. Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just an example): https://ladybird.org/newsletter/2026-05-31/ "The HTML parser is now written in Rust" "The Rust parser is also about 10% faster than the C++ version it replaced," I am not saying this is a systematic analysis by far, but Rust is pushing into domains…
On publicity side / propaganda / some specific areas you might have a point. Practically amount of C++ code being in active development (I wat to stress this particular point) dwarfs that of Rust despite all that high profile pressure.
Personally I consider languages as just a tool and do not get hung up when client prefers this or that and I have developed all kinds of software in many languages.
If asked for my own opinion - for general development I consider Rust very restrictive and poor expression-wise comparatively to C++, I think it is a case when developer become servant of a tool.
P.S. last sentence edited
Re: How memory safety CVEs differ between Rust and C/C++
#40C and C++ are kind of losing out to Rust right now. Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just an example): https://ladybird.org/newsletter/2026-05-31/ "The HTML parser is now written in Rust" "The Rust parser is also about 10% faster than the C++ version it replaced," I am not saying this is a systematic analysis by far, but Rust is pushing into domains…
I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful. If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.