D
David Rasmussen
Mark said:
Then you don't understand what lint is about.
/David
Then you don't understand what lint is about.
/David
M
Mystic Mouflon
Mark McIntyre said:
Just because something is 'legal' (not really an adequate word in this
sense) doesn't mean that it's the correct thing to do, does it?
A
Alan Balmer
I think you're confusing the roles of lint and the compiler.
C
CBFalconer
Mark said:
It is not. It is warning about possibly suspicious constructs,
which is a different world.
M
Mark McIntyre
There's no "what lint's about" stuff here. I'm not into the
metaphysical aspects of toolsets.
As far as I'm concerned lint's a tool, If its doesn't do what I want,
then its either
a) the wrong tool or
b) a badly implemented tool.
I happen to believe its the right tool. but IMHO a C code checker that
complains about correct C is badly implemented.
M
Mark McIntyre
I don't. I don't espcially care to argue about it but I'd just make
the point that a tool that ostensibly is intended to help clean up
your code, but which fills stdout with reams of inaccurate or
misleading error messages, is worse than useless.
M
Mark McIntyre
???
I can understand complaining about
if(x=11)
but whats suspicious about
if(x)
L
lilburne
Mark said:
lint ... | filter_out_the_error_i_dont_like
N
nrk
Mark said:
Warning: This could be substantially incorrect, or incorrectly phrased.
Corrections are most welcome.
Lint has a separate boolean type which can only be generated by logical
operators, and conditional expressions are supposed to have boolean type in
lint world. x may or may not satisfy that constraint. If it doesn't, lint
complains. That this annoys you is not lint's concern. lint was born in
academia with a different purpose in mind.
Part of the idea behind lint (atleast initially) was stricter type checking
(which is now commonly acknowledged to be a very wise thing indeed) so that
more errors are caught by static analysis. As has been correctly
mentioned, lint has a totally different purpose from a C compiler. What is
legal C is not necessarily a correct program. lint and its future
derivatives try to bridge the gap between "what you said" and "what you
want done". This is an admirable and extremely difficult (if not
impossible) goal.
I haven't been a big fan of lint as it does produce too much clutter, and
its stricter standards are almost impossible to adhere to by any human
coder. To be fair, the primary driving force behind lint wasn't
necessarily usability in real world. To quote from:
http://www.cs.virginia.edu/evans/pubs/tr628.ps
<quote>
Although LCLint is intended to be a pragmatic and useful tool, the primary
motivation behind its development is to investigate the possibilities of
using specifications to do lightweight static checks on source code. By
developing LCLint, we hope to learn if using specifications to check source
code can be a practical and effective way of improving software quality. We
also hope to gain an understanding of how the desire for static code
checkers may influence the design of formal specification languages and the
adoption of programming conventions. By using LCLint in a variety of ways,
we hope to learn if and how such a tool can enable better software
engineering, reduce the effort required to develop good programs, and help
us understand and maintain existing programs.
</quote>
However, splint provides command line options that can control most of the
annoyances, and when used appropriately improves productivity and code
quality considerably (in my case atleast).
August Derleth is incorrect in asserting:
The fact is that lint is trying to enforce a subset of standard C that it
considers to be safer/better. Just because something is correct according
to the standard doesn't mean it has to be correct in lint's view of the
world. If this were true, lint's utility is highly questionable.
Also in splint, +boolint +ptrnegate +boolops +charint will take care of that
annoyance (mostly).
-nrk.
C
CBFalconer
Mark said:
and "if (x == 11)", which is pristine. Another thing to watch for
is "if (x = y + z)" which is also valid, but suspicious. Yet that
last is a very useful construct. The first is normally caught by
insisting that "if (CONST == variable)" be written with the CONST
first.
Note that every snippet above is legal C code.
Assuming x is an int in both cases, the first allows for no
misconceptions barring a typo. The second _could_ be a typo or
other error, even though it is valid code. Valid code does NOT
mean correct code. So you usually have several choices - write
code that cannot be misconstrued, as in the third, annotate the
statement to suppress the warning, or use various configuration
possibilities to suppress all warnings of this type.
Splint, lint, pclint etc. should not be used before the source
passes the compiler. So there should be no gross syntax errors.
By now you are interested in having your attention drawn to areas
that *may* deserve further review.
R
Richard Bos
lilburne said:
s/error/dozens_of_errors, by which time your command line will be a
couple of dozen screen lines long.
Richard
L
lilburne
Richard said:
If you believe that then you are working too hard.
M
Mystic Mouflon
Write a script to do the filtering. You could call it
'filter_out_the_errors_i_dont_like'! Perl would be a good choice.
M
Mark McIntyre
On 5 Feb 2004 07:33:11 -0800, in comp.lang.c ,
Yeah, but then I'd have to lint the script, in case I had some bugs in
it....
Seriously tho, if I filtered it, I might filter real errors by
mistake.
Yeah, but then I'd have to lint the script, in case I had some bugs in
it....
Seriously tho, if I filtered it, I might filter real errors by
mistake.