4 ms·

> 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

> 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?

pjmlp 9y ago
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.
- huhtenberg 9y ago
  > 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".
  - pjmlp 9y ago
    > 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.

> 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?

pjmlp 9y ago

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.

huhtenberg 9y ago
> 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".
- pjmlp 9y ago
  > 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.