[dpe82]

C and modern C++ are so different that lumping them together in a blanket assertion doesn't really carry much meaning.

[steveklabnik]

It is true that they are different, but also, given the significant overlap between the two, people will reasonably talk about them together.

[Wumpnot]

From a safety perspective they aren't very close, there is a reason that all these CVE bugs are C code.

[steveklabnik]

I haven't seen conclusive evidence that this is the case, do you happen to have an analysis of this somewhere?

Of course, C++ offers you tools that C doesn't, but some of those tools have their own sharp edges as well. Plus, many C++ codebases are "C with classes" style or similar hybrids, those are still ultimately C++ programs, not C ones.

[GoblinSlayer]

Counterexamples would be s2n, grpc, putty, postfix, that are either C with classes or non-PDP C. I suppose in postfix security design was an afterthought and added gradually, but at least it was thought.

[steveklabnik]

I think this means you're making the opposite argument that most C++ folks do, which is that C with classes is bad, and more prone to security issues than "modern C++" is.

[GoblinSlayer]

My argument is that C with classes is bad when it uses bad security practice, not because it must be bad.

[pjmlp]

If the code compiles with a C++ compiler, for better or worse it is C++ as well, might be C style C++ code, which is nonetheless part of the grammar, semantics and libraries defined by ISO C++ standard.

And that is the deal, lack of security culture.

[pjmlp]

If only didn't exist so many folks that insist in using C types, and C headers, in modern C++ code.

[dpe82]

Indeed.

[harrison_clarke]

i think part of it is that if you have one in your project, it's nearly frictionless to have both. the toolchain is the same, and especially if you're using C++, you can and often do have C dependencies