Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

"If you are not using modern tools like valgrind/coverity/whatever, you are not comparing C fairly to contemporary languages."

I personally consider C + strong static analysis tools to be an entirely different language. I fully acknowledge this is my personal opinion.

Consequently, I consider it equivocation in this sort of context to be talking about C when convenient, then talk about C + strong static analysis tools when convenient. You're only programming in one or the other. My utter contempt is for C the language by itself. This is relevant because as near as I can tell, C has at least a 10:1 advantage in the field over C + strong analysis tools, and I'm probably off by at least a factor of magnitude. It is not realistic to pretend that C programmers are using these tools at scale. (Now, you can point at a ton of high profile C programs that do use these tools, because high profile C programs are exactly where they get used. But as near as I can tell they are firmly the exceptions, not the rule. And you can point at a ton of high-profile projects that don't use them, too.)

If everybody started using all these tools, including the ones that you actually have to buy because there's no open source equivalent of, it is true that most of my issues with C would be resolved. It would also be true that programmers would be a lot less gung-ho about C, though, because as anyone who has deeply integrated these strong tools into their workflow can attest, C + strong analysis tools is a much more complicated language. Now, in my opinion, that complication is being revealed by the analysis tools, not created, and all C code is actually that complicated and the programmers are merely kept in the dark by C's extensive structural deficiencies that make it so it's only safe to write in with these rather sophisticated tools, but the end result is still you're working in a much more complicated, demanding language with a much more baroque compilation process. Claims about C's productivity, compiler speed, probably execution speed, ease of programming, probably quite a few other things, all go flying out the window if this is the solution, and C looks eminently more replaceable.

We have not escaped the "wishful thinking" yet. Do I want there to be a replacement? Yes. I do my coding in other languages.

Have I grown weary of the attacks on C? Also yes.

Are not enough people using advanced toolchains? Yeah. I agree with that. But, this is effectively the same complaint that not enough people are using higher level languages. With the exception that fitting some of the extra tools on there is easier than switching languages.

Lint was created for C in 1979.

In Dennis own words:

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."

Taken from https://www.bell-labs.com/usr/dmr/www/chist.html

We are in 2016, and static analysis is still ignored by the majority of C programmers that "just get work done".

Lint has a history of being proprietary.

The Free Unixes of the true UNIX DNA lineage have a lint that is a rewrite by Jochen Pohl (done for NetBSD sometime in the early 90's?) Somehow BSD didn't inherit lint. If you use lint on BSD, you're not literally using that program that dates back to 1979.

Other Lints like FlexeLint are proprietary.

C spread like wildfire in the 80's, but an implementation of lint did not follow. Most non-Unix systems that could be programmed in C did not have a lint accompanying that C compiler.

Definitely, it seems there was a lack of promotion of lint from the birthplace of C.

If I were to give a definition of lint, it would be: "that mythical C checking program everyone knows but hasn't used".

It must be suffering from a curse which affects all technology named using a four-letter word starting with L. (Or at least LI.)

> C spread like wildfire in the 80's,

Maybe on US, I only got my first contact with C in 1992, via Turbo C 2.0.

Before that already had used multiple languages and was using Turbo Pascal 6.0 by the time I learned C.

Then again, I hardly knew anyone with access to UNIX, my first contact being Xenix in 1994.

This type of experience was quite common in Portugal, who had money to buy expensive UNIX workstations....

Also the fact of being proprietary, well I usually paid for my tools, before FOSS started to be a thing.

And on the same place where they had Turbo C 2.0, they also just got Turbo C++ 1.0.

So there was a tool that had the type system that allowed me to bend C to be more like Turbo Pascal, provided I cared to use the said type system improvements.

Which lead to me never using C++ as an improved C compiler, rather taking advantage of C++ type system to ensure my arrays and strings were properly bound checked, and IO was done safely.

Oh and taking part on C++'s side on the whole C vs C++ USENET debates, since 1994. Or type safety in systems programming vs C.

So these HN and Reddit discussions regarding the C's unsuitability to write safe software, are hardly anything new to me.

Not just C programmers. I write mostly VB.Net, C#, Java, and I can never compile any of the programs that I work with (created by teams of smart people) with all warnings treated as errors, never mind any more sophisticated analysis.

And the justification is always the same, just as you said: "just get work done".

Apologies if this is rude, but I'm not sure what this is getting at. I know that static analysis is old. I also know that I have been guilty of ignoring it sometimes. Especially as I was learning.

I think it is still in the wishful thinking world to think "better tools" should have won by now.

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.

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 :)

It is not helpful to characterize a discussion of C's problems as C-bashing. H2C03 titled his article "Let's Stop Bashing C" , but the article he was responding to was not a rant against C. It was actually a suggestion that some of the more dubious features of C should not be carried forward into future languages. You may disagree with specific issues (I am with H2CO3 on braces), but I think you agree with the principle.

Indeed. When we look at Valgrind for instance, that only runs on Linux (and not all architectures). So you can only use it to debug C code that you can port to Linux (which requires it to be portable, which is different from "correct"), and you can only debug those issues in that code which you can reproduce in that Linux port.

Reply on news.ycombinator.com