Live data from Hacker News

How memory safety CVEs differ between Rust and C/C++

kobzol.github.io

31–40 of 270 posts

Re: How memory safety CVEs differ between Rust and C/C++

#31

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…

[dead]

Re: How memory safety CVEs differ between Rust and C/C++

#32

Unsafe 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).

[flagged]

Re: How memory safety CVEs differ between Rust and C/C++

#33

Earlier 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]

I'm a huge fan of Rust! I like to think my writing makes the Rust community better more than it annoys people :)

Re: How memory safety CVEs differ between Rust and C/C++

#34
post #29

Is 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…

If I were doing a code review, I would probably accept the code either with or without the assertion. The context of curl_getenv() makes it clear that null is not acceptable. If the author of curl_getenv() had evidence that callers are frequently breaking the contract by passing null, then perhaps the assertion would help shed some light on violators. Otherwise, I would expect everyone to play by the rules, making the assertion unnecessary.

Re: How memory safety CVEs differ between Rust and C/C++

#36

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…

[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 there's some proof to any of it.

Re: How memory safety CVEs differ between Rust and C/C++

#37

Earlier 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…

[flagged]

Re: How memory safety CVEs differ between Rust and C/C++

#38
post #5

Earlier 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.

Supporting evidence for this: https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...

Re: How memory safety CVEs differ between Rust and C/C++

#39

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…

>"are kind of losing out to Rust right now"

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++

#40

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…

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.

I think the difference in languages that allows for faster performance is that Rust does a good job of surfacing expensive operations and it makes defensive programming less of a requirement.
Post reply on HN