lint fails to be my friend

Stephen Uitti suitti at ima.isc.com
Fri Apr 5 07:28:37 AEST 1991


In article <380 at ptcburp.ptcbu.oz.au> michi at ptcburp.ptcbu.oz.au (Michael Henning) writes:
>das at eplunix.UUCP (David Steffens) writes:
>
>>Try the following on your favorite flavor of lint.
>>main()
>>{
>>	int baz[10];
>>	if (baz[2] == 0)
>>		printf("Eh?\n");
>>	exit(0);
>>}
>
>The reason is that 'baz' is an array, and lint cannot check whether an
>individual array element has been initialized, since that cannot always
>be figured out at compile time. The net effect is that you *never* get
>a warning if you use an array element that is not initialized.

It could try, and in this case, it sure can.  The 'baz' array is
a stack variable, with local scope.  If baz[] wasn't initialized
within the curly braces, it wasn't initialized.

SysV lint (maybe others) complain that main() may return a random
value to the environment - so maybe "return 0;" would be better.
With ANSI C, exit() is essentially part of the language, so maybe
lint could be better.

Traditional 'lint' uses the 'pcc' parser.  Great.  If 'pcc'
didn't care, then 'lint' can't derive the information.  What have
you saved?  Many C compilers, 'pcc' included, have poor exception
handling.  How often have you gotten "Syntax error" when the
compiler should have known that it got "foo" when expecting one
of a small number of tokens?  I've worked with compilers that
tell you what they expected.  Once you get used to it, it is
extraordinarily helpful.  Our friend 'lint', says "Syntax error"
too.

Lint belongs in the compiler, anyway.  Turbo C generates
considerably more complete checking during compilation than
'lint' ever did, at over 3,000 lines per minute on a 7 MHz 8088 Pc/xt.

Stephen.
suitti at ima.isc.com
"We Americans want peace, and it is now evident that we must be
prepared to demand it.  For other peoples have wanted peace, and
the peace they received was the peace of death." - the Most Rev.
Francis J. Spellman, Archbishop of New York.  22 September, 1940



More information about the Comp.bugs.4bsd.ucb-fixes mailing list