[saghm]

> 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

[pjmlp]

The recipe is tame C and C++ as much as possible, on the language level, toolchains and hardware memory tagging, following by writing new code in something else like Swift.

See Meet with Apple, security event.

Naturally they aren't going to throw away LLVM, DriverKit or Metal Shading Language, so there is a compromise there.

[saghm]

My point is that there are plenty of smart people touting various recipes for safe C++, but somehow vanishingly few instances of actually safe C++ codebases. It's hard not to feel like the claims that C++ can be made safe are mostly being made from an abstract theoretical viewpoint and not a pragmatic one, because even the companies with the most resources or the smartest people don't seem to be able to pull it off.

[pjmlp]

Agreed, however I would vouch it is a matter of culture beyond anything else.

Dennis Ritchie had this to say about C,

> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

So lint aka static analysis, exists since 1979, and yet in 2026 one still has to advocate for stuff like clang tidy to be used.

Now you can argue that the right way would be to fix the language, not outsource to a linter, yes although the same could be told about clippy versus improving Rust.

Just like even though C++ frameworks always had the option to have bounds checking enabled, it took until C++26, under industry and government pressure, to make it officially part of the standard.

Community culture is a big deal, and hence why you don't see everyone using unsafe (or similar) all over the place in memory safe languages, and it is a big deal to even improve C and C++ safety by at least adopt the tooling that is already there.

[saghm]

I think I agree with your points on tooling. As much as I'd prefer that new projects used Rust instead of C++, I don't have any illusions that C++ isn't going anywhere any time soon, and any sort of static checking that gets introduced for C++ codebases is an improvement compared to not using it. If anything, it seems even more necessary when there are things that the language will likely never be able to check (without breaking changes, which would be controversial to say the least).