And yet we keep seeing memory safety issues in C++ code even when that code was written greenfield long after 1995. (E.g. IIRC cloudflare's cloudbleed was in a codebase that had been started in about 2012).

Looking at this, that is not clear. The report below (courtesy of Wayback Machine) mentions some external HTML libraries, as well as the development of modules that plug into NGINX, and work on raw memory buffers (I'm guessing, dictated by NGINX). Hard to speculate without seeing the code. Not that it's an excuse; greenfield C++ code could find ways to interface in a bullet-proof way with something or anything that communicates using low-level buffers.

The "Ragel" tool they used evidently generates C that uses raw pointers:

> The Ragel code is converted into generated C code which is then compiled. The C code uses, in the classic C manner, pointers to the HTML document being parsed, and Ragel itself gives the user a lot of control of the movement of those pointers. The underlying bug occurs because of a pointer error.

The bug in these Ragel-generated parsers was somehow hidden or compensated for by some buffering strategy, which they tweaked when introducing some new kinds of parsers "cf-html". Those didn't have the bug, but the different buffering turned on for them exposed the bugs in the Ragel based parsing.

https://web.archive.org/web/20170223233000/https://blog.clou...

I'm looking at the Ragel State Machine Compiler user guide. Chapter 5 (Interface to Host Program) makes it quite clear what sort of thing the Cloudfare people chose to grapple with. Ragel will write code for you planted into middle of any C function anywhere; you must provide numerous predefined variables, some of which are pointers to data, and so it goes. For some languages, there are safer interfaces: for Java and Ruby there is a buffer and instead of a pointer there is an index into it. Ragel could have been upgraded to have actual C++ support of some kind.

Because what helped C++'s adoption, copy-paste compatibility with C, is also its acquiles heel, no matter how much the security gets improved.

Cloudbleed was found out in C code, with the usual issues dealing with bounds in C.

If C++ adopted a way to namespace safe or unsafe code (unsafe by default would keep retro-compatibility) and had the tooling needed to catch memory safety bugs at compile time, that would be enough for me.

The effort needed on tooling would be significant though. I don't see that happening and overtaking Rust.

(btw the correct spelling is Achilles, Achilleus, Akhilleus, Ἀχιλλεύς)

I feel the same, despite its warts I still like coding in C++.

VC++ has some annotations on that sense, problems are two fold, get the vendors to agree, and the C subculture that security actually matters.

Thanks for the correction.

GNU and Clang toolchains have useful diagnostic abilities in this direction, though no single "master switch".

For example, with -Wold-style-casts you can diganose every use of the (TYPE) EXPR casting notation, which is often seen in the lower-level C-like C++ code for punning memory.

Somewhere in some commonly included header for the project you can write declarations for C functions that should not be used, marking them deprecated. Then if people introduce strcpy or malloc or whatever you don't want, that can be diagnosed (and can fail compilation, if desired).