Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kobzol.github.io

Post reply on HN
Print view View original

151–160 of 270 posts

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

#151

Post by eptcyka »

f33d5173 wrote: post #93
eptcyka wrote: post #61

Earlier quoted context omitted.

Ye, sure, but Rust won’t compile a `foo(std::ptr::null())`, if the function is defined as `fn foo(b: &Baz)`. C doesn’t get that luxury. That is the point of the article.

$ gcc -Wall -Werror -x c - :1:37: error: null passed to a callee that requires a non-null argument [-Werror,-Wnonnull] 1 | void f(int x[static 1]){}int main(){f(0);} | ^ ~ :1:12: note: callee declares array parameter as static here 1 | void f(int x[static 1]){}int main(){f(0);} | ^~~~~~~~~~~ 1 error generated. It can be done, though it usually isn't.

`int x[static 1]` isn’t exactly intuitive when one wants to define a reference to an integer. Nor is this practical given a dynamic array of integers. Or a single integer field in a struct.

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

#152

Post by saghm »

bitbasher wrote: post #71
anuramat wrote: post #67

Earlier quoted context omitted.

> supply chain risk how is rust special in this regard?

Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. 1. Each crate you depend on generally comes with dozens of its own dependencies. 2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies. 3. Cargo comes with "build.rs" for compile time code execution. Basically, your code…

> Point #4 is personal for me. I have multiple crates published on crates.io and I cannot log in and manage them because I deleted my GitHub account a long time ago. I wonder if someone could create a GitHub account using my name and claim ownership of them...

Why not just make a throwaway account with that username and test it, and if it works, just don't save the password or ever log on again? If it's something you care about personally and it's really been that long, I'm kind of confused why you haven't already tried this rather than just vaguely implying risk that seems pretty straightforward too verify. (It's fine if you just legitimately don't care, but it doesn't seem like it's really a personal issue for you in that case)

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

#153

Post by saghm »

360MustangScope wrote: post #30
shevy-java wrote: post #15

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 don't think it's due to Rust being inherently faster, but there have been plenty of documented cases of being able to take better advantage of concurrency due to the guarantee of no data races. Trying to do the same in C++ would expose new risks to UB, at which point you're just kind of back to the same safety argument that presumably motivated the move to Rust in the first place

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

#154

Post by saghm »

tick_tock_tick wrote: post #87
tialaramex wrote: post #46

Earlier quoted context omitted.

> 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. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Nev…

Until Rust has equal meta-programming support to C++ it's always going to be "slower". That's why people always say this because it's always true there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust. Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ t…

> there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust

The point the parent comment is making is that this doesn't really matter if no one actually does do these things in C++. It's absolutely wild to me how quickly the arguments in favor of C++ instead of Rust have reversed in about a decade; people used to argue that the benefits of Rust were all theoretical and in practice people who were used to C++ could write it perfectly fine without safety issues, and now it's somehow that the theory that gives C++ the advantage and we don't need to care about whether those supposed advantages ever actually exist in practice.

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

#155

Post by saghm »

tialaramex wrote: post #43
ghosty141 wrote: post #24

Earlier quoted context omitted.

> but Rust is pushing into domains where C and C++ dominated in the past. I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)

A not inconsiderable part of why is that Rust for Linux did the work. When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest. Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the l…

Honestly this just makes it sound like C++ people either didn't really care about it in practice or just were weirdly insistent that they get to decide how to integrate the language into an existing project. At best, it's just another instance of the claims that C++ could totally do everything Rust does (but somehow still never seems to in real life), and at worst it just kind of reflects poorly on the social skills of the people who tried to push it.

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

#156

Post by saghm »

Decabytes wrote: post #90

Bjarne Stroustrup was recently interviewed by Ryan Peterman^1 1. https://youtu.be/U46fJ2bJ-co?t=2780 and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either 1. Being written in C style C++ and not using "Modern C++" 2. Being written in C He then goes on to say say that Modern C++ and where it is necessary, hardened libraries…

> He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues.

I'll believe this when he can actually point to non-trivial, real-world C++ codebases that have managed to avoid having memory unsafety following these techniques. "It's technically possible for this issue to be avoided" is a lot easier to say than it is to actually make work in practice.

If Apple and friends have a secret recipe for avoiding C++ memory vulnerabilities, maybe they should start using it to avoid stuff like this: https://nvd.nist.gov/vuln/detail/CVE-2026-20700

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

#157

Post by jpc0 »

okanat wrote: post #91
thegrim33 wrote: post #65

Really annoying when people take 50 year old C code and modern C++ code and just drop them into the same bucket and refer to them as if they're the same thing. The CURL example they give has multiple modern C++ solutions that accomplish the same thing without UB.

I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into "rewrite every single thing now in Rust" but one component at a time when the project justifies it. So, tell me what compiler option disables non-moder…

Enable sanitizers on test suites and fuzzers.

Enable warnings and WError

Use clang tidy and other static analyzers

Actually use a modern compiler and enable the safety features they ship with

Most of these things have solutions that would take years of work in an existing project so it isn't done

And it takes significantly more effort to write good modern C++ code than Rust code

So Rust wins

But I don't like writing Rust code, I do enjoy writing modern C++ code, the tradeoff is modern C++ can be a tooling nightmare... Try shipping a modern stdlib on an old platform, it is truly infuriating, I don't want to be a build systems expert but I need to be to use a safer alternative.

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

#158

Post by physicsguy »

john_strinlai wrote: post #42

> Because sometimes I see people online who compare the number of CVEs in Rust and C/C++ software, [...] a rule of thumb i follow is that the second someone starts comparing or talking about the number of CVEs, i just ignore whatever they say next. its hard to think of a more useless metric than "number of CVEs", especially now. (edit: the people disagreeing are encouraged to share how you use "number of CVEs" to inf…

It's alright, just get ISO27001 and list them as risks!

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

#159

Post by blub »

josephg wrote: post #131
Decabytes wrote: post #90

Bjarne Stroustrup was recently interviewed by Ryan Peterman^1 1. https://youtu.be/U46fJ2bJ-co?t=2780 and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either 1. Being written in C style C++ and not using "Modern C++" 2. Being written in C He then goes on to say say that Modern C++ and where it is necessary, hardened libraries…

If these hardened libraries were as good, we wouldn't have blog posts like this[1], from the android team last year. > We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code Maybe the android team could have gotten the same benefits by simply auditing and modernising their C++ code? I'm not convinced. Google has some amazing engine…

There’s a few things happening here.

First of all, Rust is default safe. In C++ developers always trade performance for safety, in Rust they just swallow the penalty (which is often still performant enough). C++ code will often not be as memory safe as it could because someone decided to not use particular checks (like compiler-driven integer overflow checks).

Secondly, Android C++ code is not particularly high quality, also when it comes to memory safety. A lot of it is also quite old. I would consider it your average massive project, not a masterpiece coded by amazing engineers.

Thirdly, it has a massive target on its back and is under attack by pretty much everyone. They have to use whatever they can to keep up with the attackers.

Several companies have these issues and approach them in different ways. Rust is a very attractive approach for developers, since it’s just another programming language. It’s also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion. I hope it’s a stepping stone to something better.

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

#160

Post by physicsguy »

okanat wrote: post #111
bitbasher wrote: post #71

Earlier quoted context omitted.

Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. 1. Each crate you depend on generally comes with dozens of its own dependencies. 2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies. 3. Cargo comes with "build.rs" for compile time code execution. Basically, your code…

> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. Ther…

That's not really true at all though, even in very complex software it's pretty rare to have more than ~10 external dependencies in a C++ project. People tend to roll their own a lot more, partly because dependency management is a lot more painful and fragmented. Boost is effectively an extended standard library, as is abseil, but the language has got much better at incorporating back features since C++ 2011, but even so, the dependencies tend to be slow moving and fairly stable.
Post reply on HN