Hacker News Reader

Comment by pjmlp | Hacker News Reader

The thing is that the C working programming class doesn't value quality and secure code, performance FTW everything else gets done later, if there is time that is.

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.

View on HN

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.

> 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

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.

  >> 36 seems a not-unreasonable number of severe defects.

The point is that it should have been 5 defects (36 total - 31 memory defects).

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.

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.

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.

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

Yeah, there's that :)

Reply on news.ycombinator.com