Hacker News Reader

Comment by quickthrower2 | Hacker News Reader

I am not a C programmer but my opinion with any language is don’t try to catch mistakes like this in the compiler. Instead leave to configurable and competing linters for people who want to catch possible mistakes like this. Anyone caught by this mistake probably hasn’t tested their program adequately. Any mistake induced by the wrong constant number should be easy to weed out with unit testing.

View on HN

Not including a linter in the earlier C compilers are one of the hughe mistakes of that area. Compilers absolutely should have linters, they are very valuable tools. Think about all the common security mistakes in your average C application that could have been avoided over the years with a linter.

I'm pretty sure Dennis Ritchie at some point himself said that not including a linter was a mistake, but I cannot find a quote of this with a quick search.

Back in the day most people actually ignored the few warnings compilers would give them, i do not think that having a linter would be used much (and AFAIK there were some).

"Back in the day?" Check out your system's log file for a scary collection of horror shows. Or compile most packages these days.

In defense: configuring a package that is compiled by lots of people on lots of machines with lots of versions of various compilers requires a lot of attention to warning flags and such. If you aren't starting out a package from a blank buffer it's very hard to get this right.

But I am frequently shocked by the number of compiler warnings I get from code downloaded from public repos and compiled in precisely the environments it's been documented to have been tested on.

He at least said that it was a requirement for the buggy code he saw being written.

"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."

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

By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. It's a bit different for clang, which is modular and provides libraries that tool writers can use, but gcc is intentionally monolithic.

> By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler.

Does depend on what kind of lint you want to catch but something like this 'just' needs some lexing and parsing to give a usable AST that's reasonably clean so it's not too hard to write lint rules against it. (Not trivial for C & C++ hence 'just')

Building the full compiler is much more work, especially if you want a decent optimizing compiler.

The back end is a lot of work, but so is the front end in a language like C++.

In fact most of the essential complexity is in the front end; you make do with a simple back end, but the front end is irreducibly complex if you want it to actually compile the language to spec.

And you need the front end to lint, especially if you want to avoid false positives, the bane of linting tools.

And better hope you didn't put in any bugs that GCC does or doesn't have, then you're left helpless as linter and compiler engage in epic battle on who is right.

It's not just nontrivial for C++, you need a full template engine just to properly parse it [1]. Same thing for languages with a lisp-like macro system. Or languages that allow dynamic redefinition od symbols [2].

[1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...

[2] https://www.perlmonks.org/?node_id=663393

Unit tests will not catch all issues, the person that writes the unit test will probably not see a corner case when implementing the code so it won't add the test for that corner case in the unit test either.

Or if the same person is writing the test as the code it is testing, given this is a syntax error rather than a logic error, it is likely that the test will be flawed similarly.

A test passing just means that the code and the test agree, not necessarily that both are correct.

lint was developed in 1979 (https://www.bell-labs.com/usr/dmr/www/chist.html) and we had to wait until clang for many developers start caring about actually using static analyzers.

Every external tool is a lost opportunity for quality enforcement.

Static analyzers existed long before the clang compiler. SAL from Microsoft is used extensively in every codebase I’ve worked with in Windows and it’s amazing, even if you have to get used to macros on all your functions’ parameters.

https://docs.microsoft.com/en-us/visualstudio/code-quality/u...

Surely, and I appreciate its existence.

Just making the point that they have been largely ignored.

That is not a fair assertion. You might have ignored static analyzers until you've discovered clang, but that observation is not generalizable. As others have already pointed out, lint has been used extensively for decades.

I have been using static analysers since the mid-90's.

Ever heard of PC Lint from Gimpel? It was my first one.

Or do you think I would be critic of how many use C, without adopting best practices myself?

One learns a lot about code quality, or lack thereof, when doing enterprise consulting.

> One learns a lot about code quality, or lack thereof, when doing enterprise consulting.

Pure truth, there. One has seen neither really awful code nor really great code until they have seen the wide array of code quality produced by an enterprise with a few decades of software development history. Any enterprise will suffice, it doesn't have to be a huge corporate entity.

There are a very few developers who are really good and who really care, and there are very few who really do not care and who are really not good, and most are somewhere in between.

As addendum to my reply, here are the answer to JetBrains questionnaire about the C++ eco-system among their customers.

Check "Which of the following tools do you or your team use for guideline enforcement or other code quality/analysis?" results.

https://www.jetbrains.com/lp/devecosystem-2019/cpp/

GNU's C linter is GCC warnings. For C, making a linter isn't a big deal, but for C++ writing a robust C++ parser is so hard that the linter will need to use the compiler's parser anyways.

By that logic you could get rid of a lot of warnings. TBH, I think getting good warnings is a major feature of modern compilers.

The kind of developers who are likely to make this mistake are probably not the kind of developers who will use advanced tools including linters or likely doing unit testing.

Some may even have released code that still has these time bombs waiting to occur.

Reply on news.ycombinator.com