[peterwaller]

A place where your reasoning breaks down is when one comes to define "the developer".

There are a few legendary developers in the world I would trust to write secure C/C++. Others may be able to do so, by luck.

Would I trust an organization of 2000 people all developing the same large code base? I know there are processes that can be adopted, such as using clever static analysis tools and rigorous review by security professionals.

But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again. (e.g, X=Data execution prevention, Y=Return oriented programming).

This keeps happening. It takes some arrogance to believe that a safe large system can be built in an unsafe language, these days.

[bilbo0s]

"...But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again..."

To be fair...

This issue exists with every other language as well. I would be very skeptical of any language claiming to be 100% secure.

The same is true of the developer argument. Cyclone, Rust, C#, Java... you name it... they are all capable of producing systems with security vulnerabilities owing to developer quality inconsistencies.

[JustSomeNobody]

This will happen regardless of C or C++.

[peterwaller]

I agree with this and bilbo0s. There exists no panacea. But C/C++ leave a lot of unholstered footguns lying around to play with :)