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

191–200 of 270 posts

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

#191

Post by pjmlp »

armitron wrote: post #134
okanat wrote: post #111

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

I've never seen a C program use hundreds of dependencies. This is typical in Rust (and Node). I know a few high assurance teams that dropped Rust for this very reason.

Because most of them depend on UNIX being there in first place, aka all of POSIX, alongside Khronos APIs.

Additionally, most C libraries tend to come via UNIX package managers directly, and then consumed via CMake, pkg-config or what not.

I do agree Rust dependency trees are a problem, for security, and always compiling everything from source.

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

#192

Post by pjmlp »

tcfhgj wrote: post #77
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…

I think none of this is special to Rust vs C++, except #4, because C++ doesn't have an equivalent

In 2026 it does, vcpkg and conan.

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

#193

Post by pjmlp »

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.

Because that is how the real world works, regardless of many of us get annoyed to have people coding in C with C++ compilers.

Beautiful modern C++ unfortunately only exists in conference slides, recent C++ books, and top performer teams.

My main use for C++ outside hobby coding, is to integrate native code into managed runtimes, most of the time the code looks closer to C with Classes than anything past C++11, even if it was newly written yesterday.

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

#194

Post by tptacek »

mk89 wrote: post #165
tptacek wrote: post #148

Earlier quoted context omitted.

Which compliance regime are you referring to that cares about CVE counts as a metric?

Not as a metric, but it basically becomes one, like with Fedramp. You need to fix also moderate/low CVEs within a certain time frame. So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is. It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed…

I don't do FedRAMP and will have to take your word for that, but none of SOC2, 27001, or HIPAA/HITRUST care about CVE counts.

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

#195

Post by pjmlp »

jpc0 wrote: post #157
okanat wrote: post #91

Earlier quoted context omitted.

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…

My experience is that unless that is pushed by DevOps teams, and being strict about it, no matter how long a build is broken, eventually they get disabled because there is this critical delivery, and then they are never enabled again.

Any language that isn't copy-paste compatible with C (or a subset of it), wins.

That is the biggest issue, old habits and old teaching materials keep working, a plus, and a curse.

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

#196

Post by pjmlp »

pornel wrote: post #137
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.

This doesn't change a thing, because Rust is an answer to Modern C++ still being inherently unsafe and not meeting the bar. The best that C++26 has to offer is below the basic guarantees that Rust shipped in 2015. This is the blind spot that prevents Bjarne from taking significant steps needed for C++ to catch up. He's still seeing C/C++98 as the problem to solve, while Rust sees Modern C++ as the problem to solve.

I do think he does see the actual problem, what he kind of doesn't accept/acknowledge is that in the tradition of "worse is better", most companies don't care what static analysis are out there, and that university professors have no intention to change for teaching C++ as it was taught in the 1990's.

The problem of TypeScript, is that you can still write JavaScript with all the WATs, same applies to any language that tries to be TypeScript for C.

However many of us actually think that Rust is also not the answer for everything, there are plenty of safe languages that could be used instead of C, C++, Rust for plenty of scenarios, and aren't because of cultural issues.

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

#197

Post by pjmlp »

josephg wrote: post #129
tick_tock_tick wrote: post #87

Earlier quoted context omitted.

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…

> Until Rust has equal meta-programming support to C++ it's always going to be "slower". What metaprogramming does C++ have that rust is lacking? If you need more than traits + generics, rust also has proc macros. Proc macros are essentially portable compiler extensions. They take in a stream of symbols from the user's program at compile time and emit rust code that gets passed straight to the compiler. You lose out…

> What metaprogramming does C++ have that rust is lacking?

Compile time execution, and compile time reflection, with the same syntax.

Proc macros are still a kludge having to depend on syn crate, and some stuff used to depend on nightly, is that still the case, I don't keep track?

Additionally type specialisation, and explicit templates.

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

#198

Post by pjmlp »

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…

> C and C++ are kind of losing out to Rust right now.

Depends on the domain, there are enough fields where Rust still doesn't have an answer for.

Example, the compilers it depends on (botstraping on Cranelift when?), Khronos and POSIX industry standards, HFT, HPC, console devkits, AI frameworks, VFX reference platform,....

It will get there, eventually, maybe.

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

#199

Post by pjmlp »

ghosty141 wrote: post #24
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…

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

Because Linus, plenty of other OSes have adopted C++ on their internals.

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

#200

Post by pjmlp »

cesarb wrote: post #119
tialaramex wrote: post #43

Earlier quoted context omitted.

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…

> their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software That has already been done in the past. Quoting the FAQ: "[...] the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a di…

Yet the C compilers they use are written in C++.

It was mostly a Linus issue, and not wanting to fix what were the root causes of the regressions.

Post reply on HN