Hacker News Reader

Comment by roca | Hacker News Reader

There isn't anything new here to defend against lifetime-related UB. For that it simply references https://arxiv.org/pdf/2503.21145, which is just a summary of existing dynamic mitigations --- which don't fix UB at the language level, impose performance tradeoffs, and in the case of pointer integrity, require hardware support that excludes e.g. x86.

Look at it this way --- mature products like Chrome are already doing all of that wherever they can. If it was enough, they wouldn't worry about C++ UB anymore. But they do.

View on HN

At this point I'm wondering if C++ leadership is either willfully ignorant or genuinely in denial.

I know several people on various C++ committees and by and large their opinion is, we evolve the language and library to give existing projects incremental improvements without asking them to rewrite them, but if you are starting with a new project C++ is often a subpar option. From that perspective I get why they'd be hesitant about efforts like Circle. Circle and co. ask developers to rewrite their code, in something that looks very different to normal C++ - whatever normal C++ even is, given the multitude of dialects out there - can't seamlessly interop with existing code, needs a new incompatible standard library, that as of now doesn't even exist. At which point, honestly just rewrite it in Rust instead of going through the painful exercise to use something that's 10+ years behind where Rust is today in terms of DX, tooling and ecosystem.

But all that doesn't explain why at the very top, even mentioning Rust as an alternative seems taboo, idk.

There is also a strange dynamic going, and this has worked against C++.

In the early ISO days, the people sent to ISO were employees from compiler vendors, and existing practice was the key factor into adding stuff to the standard.

Eventually, comitee dynamics took place, and nowadays most of the contributors to WG21, and to lesser extent WG14 (which still keeps more close to the existing practice spirit), you have hundreds of contributors wanting to leave their historical mark on the ISO standard, withough having written a single line of compiler code, validating their proposal, which they are able to fight trough the whole voting process, and then leave the compiler vendors sorting out the mess how to implement their beloved feature.

Those of us that really like C++, are also kind of lost on how things turned out this way.

WG21 is well down the path of actively being hostile to the implementers of C++. There was a recent proposal where all 4 implementers [1] stood up and said "no", and the committee still voted it in, ignoring their feedback.

[1] C++ has only 4 implementations these days, Clang, EDG, GCC, and MSVC; everything keeping up with the standard is a fork of one of these projects.

This is why I see C++26 as the last great standard, it would likely be C++23 if it wasn't for reflection.

Not that WG21 won't produce further ones, just like has happened with other ecosystems of similar age, who cares about Fortran 2023, or COBOL 2023 revisions, despite their critical use in many research projects, or companies infrastructure.

It is already good enough (minus the security issues), for the existing infrastructure that relies on C++, and most of the new stuff isn't helping.

Which proposal?

Proof of implementation should be a requirement for every proposal (allegedly it is, but in practice...).

Which would limit most "outsider" proposals mostly to library features, which would be a good thing I guess.

Well, you kind of have your answer right there: it’s a language designed by committee, not by “the industry”.

This has been my biggest problem, and I say this as someone who has been on and off developing C++ for over 2 decades.

At the same time, it’s a safe bet to say that C++ will still be around in another 2 decades.

Don't forget that same applies to C.

And COBOL.

Yeah, however at least COBOL wasn't designed without bounds checking, or pointer based strings, in 1959 hardware.

In 1959 people still made mistakes. By the time C came around, human error was all but eliminated. /s

> even mentioning Rust as an alternative seems taboo, idk.

Rust is even framed as an "attack on C++" by Stroustrup himself [1]. No wonder it's taboo.

[1] https://www.theregister.com/2025/03/02/c_creator_calls_for_a...

Seems like a bit of a sensationalist deduction from what looks like a pretty levelheaded response. It's not a call to war, but call to improve the C++ standard

The Register article was written based on a leaked paper, since then, Bjarne published the article itself, which you can read here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p36...

Not trying to take a position about if it's sensational or not, just wanting to add a primary source here.

C++ developers worry about all UB, but we don't worry about all of them to the same extent. MITRE's CWE Top 25 [1] lists out-of-bounds write as the second most dangerous weakness, out-of-bounds read as the sixth, and use after free as number eight (null-pointer dereference and integer overflow are at nos. 21 and 23 respectively). All UBs are worrisome, but that's not to say they are equally so. Taking care of out-of-bounds is easier than UAF and at the same time more important. Priorities matter.

[1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

I don't know where that ranking comes from. It also matters that attackers adapt: UAF exploitation is harder than out of bounds, but it is well understood, and attackers can switch to it, so shutting off one source of UB isn't as effective in practice as you might expect.

> I don't know where that ranking comes from.

It comes from MITRE (https://en.wikipedia.org/wiki/Mitre_Corporation), and the methodology is explained on the website (roughly, the score is relative prevalence times relative average vulnerability severity).

> and attackers can switch to it, so shutting off one source of UB isn't as effective in practice as you might expect.

If that's how things work, you could say the same about all the other weaknesses that have nothing to do with UB.

Interesting, for all the winging about C or C++ this shows most of these apply to all languages, and the ones that relate to C or C++ are actually pretty easy to prevent in C++(less so in C) by enabling hardening modes and using smart pointers.

Because these are ranked by prevalence x severity, and most programs are written in memory-safe languages, the UB-related weaknesses are probably at the top of the list for programs written in C or C++, especially because "ordinary" servers are usually not written in those languages. But the point is that, indeed, even within these unsafe languages, not all kinds of unsafety are equal.

It is true to say that memory-safety issues are among the biggest problems in C and C++, but it is not true to say that unless you absolutely prevent them all you remain in the same spot. If you significantly reduce or prevent some of the memory safety issues, you're in a place that's not too different from that of programs in memory-safe languages.

Reply on news.ycombinator.com