[rippercushions]

Writing the critical parts of a OS kernel in C is sensible. Browser extensions, not so much.

As the author notes, they're not just being snobby about languages, the main issue with C from a security POV is the total lack of memory safety and the consequent vulnerability to buffer overflows.

[Kamq]

> the main issue with C from a security POV is the total lack of memory safety and the consequent vulnerability to buffer overflows.

Sure, but C++ also has these issues, so the "not even C++" doesn't exactly make sense.

[palant]

Disclaimer: I am the author of this article.

Not really. With C++, you don’t have to use manual memory management. In the typical scenario, C++ objects take care of memory without the developer having to think about it. And you have all kinds of smart pointers for the more complicated scenarios.

That doesn’t mean of course that there are no buffer overflows in C++, or use-after-free bugs. There is still plenty of room for mistakes. But C++ code following best practices tends to have far fewer vulnerabilities than comparable C code.

[Kamq]

We have... very different ideas about how capable random devs on a government contract are. Or how feasible it is to prevent the worst possible behavior in a large codebase. That is to say, I tend to assume code managed by a large team on a government project (or a project in any sufficiently large organization) will be the worst possible code that language can produce. And C++ can produce worse code than C (all of the danger of C, but happening implicitly instead of explicitly).

You seem to be taking the best possible code as the default. I will admit that the best possible C++ code is better than the best possible C code.

[Too]

At least c++ has unique_ptr and friends. Standard containers like string, vector and map also reduce the amount of manual fiddling with fundamentals you need to do yourself, greatly reducing the mistake-surface.

But yeah, in the end both of them are very dangerous tools, compared to other alternatives.