Any C/C++ LINT type checking recomendations

[David Rasmussen]

And I agree with August that lint is incorrect - lint should not be
complaining about legal constructs.

Then you don't understand what lint is about.

/David

 

[Mystic Mouflon]

And I agree with August that lint is incorrect - lint should not be
complaining about legal constructs.

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?

 

[Alan Balmer]

And I agree with August that lint is incorrect - lint should not be
complaining about legal constructs.

I think you're confusing the roles of lint and the compiler.

 

[CBFalconer]

.... snip ...

And I agree with August that lint is incorrect - lint should not
be complaining about legal constructs.

It is not. It is warning about possibly suspicious constructs,
which is a different world.

 

[Mark McIntyre]

Then you don't understand what lint is about.

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.

 

[Mark McIntyre]

I think you're confusing the roles of lint and the compiler.

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.

 

[Mark McIntyre]

It is not. It is warning about possibly suspicious constructs,
which is a different world.

???
I can understand complaining about
if(x=11)

but whats suspicious about
if(x)

 

[lilburne]

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.

lint ... | filter_out_the_error_i_dont_like

 

[nrk]

???
I can understand complaining about
if(x=11)

but whats suspicious about
if(x)

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:

lint and lint-like programs are annoying to the point of uselessness.
They consistently warn about things that /are not wrong/, /never have
been wrong/, and /are not even dangerous/. There's one example that
sticks out in my mind:

int x = 1;

/* code */

if (x) return y;

will always generate a warning with a lint-like program. Why? Because
x is not a `boolean' in lint's view of the world, even though the
relevant standards expressly and specifically allow scalars (such as x)
to function in a boolean context. lint is wrong, the standards are right
(axiomatically), and lint hasn't been fixed.

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.

 

[CBFalconer]

???
I can understand complaining about
if(x=11)

but whats suspicious about
if(x)

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.

 

[Richard Bos]

lint ... | filter_out_the_error_i_dont_like

s/error/dozens_of_errors, by which time your command line will be a
couple of dozen screen lines long.

Richard

 

[lilburne]

s/error/dozens_of_errors, by which time your command line will be a
couple of dozen screen lines long.

If you believe that then you are working too hard.

 

[Mystic Mouflon]

s/error/dozens_of_errors, by which time your command line will be a
couple of dozen screen lines long.

Richard

Write a script to do the filtering. You could call it
'filter_out_the_errors_i_dont_like'! Perl would be a good choice.

 

[Mark McIntyre]

On 5 Feb 2004 07:33:11 -0800, in comp.lang.c ,

Write a script to do the filtering. You could call it
'filter_out_the_errors_i_dont_like'! Perl would be a good choice.

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.