Problems with lint as a seperate program
Mike I'll be mellow when I'm dead Meyer
mwm at ucbopal.berkeley.edu
Sat May 10 15:26:16 AEST 1986
Just so that people don't assume that having lint-like things as a seperate
program is right, with no problems, I'd like to point out one: on at least
one occasion, lint didn't accept quite the same language that cc did. Unless
lint it just cc with a magic flag, somebody has to make sure that the lint
tracks cc (even if it's only making sure that lint gets recompiled whenever
cc changes).
I've been using a C compiler that has much of the lint-like checking built
in (uninitialized and unused variables, constant references beyond the
ends of arrays, type clashes and the like). It's GREAT! It's not a complete
lint, in that it won't help you verify that your code will port to other
machines, but it catches most of the coding errors that lint does, and
issues warnings so that it doesn't mangle the 1% of the cases where they
are correctly used.
I think most C compilers would benifit from having these types of checks
built in. Those obsessed by portability will disagree, because people
would be less likely to run lint. But you can still lint code if you
wish, and it makes the job of writing running code easier.
<mike
More information about the Comp.lang.c
mailing list