They are also the projects that get the most attention. I wouldn't rule out that python/javascript/whatever projects have just as many, if not even more, security flaws than your typical widely-used C library. They are just not interesting enough to warrant the required attention. The flaws are likely to be more subtle than simple buffer overflows too, think of all the abstractions involved.

My point was "C with Classes" and "C with templates" versus modern C++ best practices.

C++ code can be quite safe, providing people stop writing C with C++ compilers.

... as are the projects that overdo on "modern C++" to the extent of introducing even more severe problems masked by the layers of needless abstraction.

CVEs don't come from C or C++. They come from the lack of coding discipline and with all other things being equal C programmers are generally better skilled and more diligent than their C++ counterparts.

> C programmers are generally better skilled and more diligent than their C++ counterparts.

That is not what the CVEs on Linux prove.

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

One would expect, on a C project with the rigor of review process that patches go through and the usual assement I keep hearing since the early 90's about C programmer skills, now repeated again by you, that Linux would have 0 CVEs reported.

The majority of exploits in C++ are related to its copy-paste compatibility with C, and devs that insist in using them in spite of the language offering safer, better, alternatives.

> That is not what the CVEs on Linux prove.

You picked one of the largest, complex and most scrutinized C projects of the whole time and compared its CVE count... to what exactly?

Exactly because it is "largest, complex and most scrutinized C projects of the whole time" and yet it is impossible to use C without producing a couple of CVEs every single month.

And a good example against the myth that the skilled C programmer that doens't produce memory corruption exists.

> Exactly

Again - what are you comparing Linux CVE counts to?

You can't point at an absolute count for A while arguing that A is inferior to B. I see nothing to support the assumption that a Linux-sized project in C++ would've have any less of CVEs.

> the myth that the skilled C programmer that doens't produce memory corruption exists.

Don't put words in my mouth. You are refuting a point that I didn't make. I said that C programmers are generally better skilled than C++ ones, which is not a "myth".

> I said that C programmers are generally better skilled than C++ ones, which is not a "myth".

So where are those statistic results available?

Every single memory corruption in C++ code can be traced back at language semantics inherited from C, thus common to both languages.

Which aren't present in C++ code bases where developers adopt C++ best practices, meaning eschewing the majority of C programming pattern, while adopting std library types, references instead of pointers, class enumerations instead of plain enums, classes to keep struct invariants, ....

History has proven on its CVE databases that the majority of C devs are not skilled at all to care about writing safe code.

Whereas one of the major points done by ANSI C++ members work is how to reduce UB use cases and reduce the possibilities of exploits, the ANSI C members decided to turn ANNEX K into an optional item in C11, and VLAs have been proven to be quite nice for stack attacks, thus not even considered for ANSI C++ adoption.