4 ms·

Okay, so I have written ... multiple projects that ran as long as they had power with no evidence of memory corruption over a span of 30 years. I've used Lint.

Okay, so I have written ... multiple projects that ran as long as they had power with no evidence of memory corruption over a span of 30 years. 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.

kazinator 10y ago
Also the skill level needed to write code that will evade lint type tools, while being incorrect. :)
- ArkyBeagle 10y ago
  Yeah, there's that :)
kazinator 10y ago
Static analysis isn't the only game in town anyway. An approach that seems to be gaining popularity is fuzzing. I'm using the AFL program (American FuzzyLop) in an ongoing way to find problems in code. Stress tests under Valgrind, and fuzzing are quite powerful.
- pjmlp 10y ago
  Assuming one is using a C toolchain that allows for it, which usually isn't the case for most embedded projects and their commercial tools.
pjmlp 10y ago
> with no evidence of memory corruption over a span of 30 years. 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. https://support.apple.com/en-us/HT206903 https://support.apple.com/en-us/HT206903
- ArkyBeagle 10y ago
  I'm not trying to say you're wrong. Especially because "...so (many) nice CVE databases full of examples". 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.
  - blacksmythe 10y ago
    >> 36 seems a not-unreasonable number of severe defects. The point is that it should have been 5 defects (36 total - 31 memory defects).
- ArkyBeagle 10y ago
  Also: "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." 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.

kazinator 10y ago

Also the skill level needed to write code that will evade lint type tools, while being incorrect. :)

ArkyBeagle 10y ago
Yeah, there's that :)

kazinator 10y ago

Static analysis isn't the only game in town anyway. An approach that seems to be gaining popularity is fuzzing. I'm using the AFL program (American FuzzyLop) in an ongoing way to find problems in code. Stress tests under Valgrind, and fuzzing are quite powerful.

pjmlp 10y ago
Assuming one is using a C toolchain that allows for it, which usually isn't the case for most embedded projects and their commercial tools.

pjmlp 10y ago

> with no evidence of memory corruption over a span of 30 years. 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. https://support.apple.com/en-us/HT206903 https://support.apple.com/en-us/HT206903

ArkyBeagle 10y ago
I'm not trying to say you're wrong. Especially because "...so (many) nice CVE databases full of examples". 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.
- blacksmythe 10y ago
  >> 36 seems a not-unreasonable number of severe defects. The point is that it should have been 5 defects (36 total - 31 memory defects).
ArkyBeagle 10y ago
Also: "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." 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.