I think it is still in the wishful thinking world to think "better tools" should have won by now.
Even the language authors were honest and:
1 - created a tool in 1979 that most C developers ignore even in 2016, 37 years later;
2 - realized that C was due its date and took part in Limbo and Go design
Yet lots of C coders continue to improve this NIST list, every single day:
https://nvd.nist.gov/visualizations/cwe-over-time
For me wishful thinking, is the mentality that there are C developers out there that manage to write memory corruption free without using such tools.
Never met any since my first contact with C in 1992.
I've used Lint. Early on. It was great training. After a while, you don't need it so much.
I think you are Vastly overestimating the skill level needed to write normatively-correct C code by quite a margin.
How many people did you had on those teams and how was the development process?
Me too I have written such software, when working in teams of no more than two people where we taken a Pascal like approach to programming in C.
Basically:
- Use translation units as modules
- structs are always exposed as Abstract Data Types, with accessors either via macros (when speed matters) or functions
- assert everywhere any assumption that can lead to memory corruption
- on debug code, make use of assert with pointer validation library from debugger, e.g. IsBadReadPtr()
- arrays are never accessed with pointer syntax
- use of compiler extensions for bound checking during debug builds
- all warnings enabled and considered as errors
And quite a few others.
I can count up to 5, the amount of friends and co-worker that managed to write good quality C code, since I learned C in 1992.
C++ unfortunately also enjoys the flaws of C due to its C copy-paste capability, but at least I can make use of the type system via structs, classes and operator overloading to enforce code that in C cannot be more than plain patterns.
> I think you are Vastly overestimating the skill level needed to write normatively-correct C code by quite a margin.
Anyway I don't need to proof anything when we have so nice CVE databases full of examples.
Or companies like Apple, which are supposed to have such ideal C programmers, do an OS release with 36 bugs, 31 of these (86%) related to C memory corruption bugs.
As I recall, you had six(?) defects identified on a rather significant subsystem. While that's hardly ideal, it doesn't sound like those six defects should cost that much to fix.
And I'm not trying to say I can achieve some abstract perfection - I will have the odd memory overwrite early in unit test. But SFAIK, I've caught the overwhelming majority of them. But I will also be able to spend several hours building scaffolding to flush 'em out... this is especially true of networked code. I tend to use Tcl to torture them.
I will say - all the old guys I knew who were good C coders just got out of coding pretty much altogether. When I see discussions from younger coders, based on the problems they have, I feel that there's been some loss of information.
Also - for a major release of something as big as El Capitan, 36 seems a not-unreasonable number of severe defects. Obviously, we'd prefer it was a smaller number, and we don't know how many will be found eventually.
>> 36 seems a not-unreasonable number of severe defects.
There you go. That's how I have done it as well. The degree of "Pascal-like"-ness is always .. something to be humble about. I really, really wish it had been Ada all along but that seems not to be likely.