Re: PCLint experiences

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
On Tue, 19 Aug 2003 09:36:49 +1200, Graeme Prentice

Quoted text here. Click to load it

PC-lint from Gimpel is simply *awesome*.

Quoted text here. Click to load it

More often than I'd care to admit.

Quoted text here. Click to load it

Ditto.


As mentioned before, it can save you significant debug time by finding
errors before they make it into your test code.

If you have formal code reviews, it can save you a bundle, if you
require a clean lint before wasting people's time.

The costs of lint are *insignificant*, even if you derive no benefit
other than peace of mind.

Quoted text here. Click to load it

Lint early.  Lint often.  Lint is your *friend*.

Every time I edit a module, I run a unit lint to find any gross
mistakes.

Just before I link test code, I run a cross-module (complete) lint to
make sure everything is copacetic.

Before I run a formal build, I run a cross-module lint to make sure
keyword expansion in revision control hasn't killed anything (it
hasn't yet, but I'm paranoid).

Lint early.  Lint often.  Lint is your *friend*.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: PCLint experiences
1.  Lint is good.

2.  You will not use it if you don't use it every build.

Just my opinion.

Bruce

Quoted text here. Click to load it



Re: PCLint experiences
Quoted text here. Click to load it

Often. It's particuarly good at catching subtle C++ problems.

Quoted text here. Click to load it

Very regularly.


It's there for the engineers to use whenever they want, but Lint reports
are included in the release process for all products.

PC-Lint has paid for itself dozens of times over. I could not recommend
it more highly.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas" HMHB


Re: PCLint experiences
On Tue, 19 Aug 2003 09:36:49 +1200, Graeme Prentice

Quoted text here. Click to load it

Excellent product.


All the time.

Quoted text here. Click to load it

Some of the time.

Quoted text here. Click to load it

Definitely recommended.


After every change, it's part of my make file. Lint errors abort the
make.

Quoted text here. Click to load it


Re: PCLint experiences

The "costs" I was referring to was the ongoing cost of the time taken
to do the linting.  I have a "legacy" project for which lint gives a
large number of errors  - I know you can turn things off.  I guess
with new software you can create "zero lint error" software and then
it only takes a small amount of time.  Thanks for all the comments.

Graeme

Re: PCLint experiences
Quoted text here. Click to load it

OK, well the issues then boil down to setting up a sensible environment
(although many are shipped with it), looking at what Lint is telling
you about your code, UNDERSTANDING what the messages mean in the
context, and deciding whether to dismiss them explicitly, modify
your Lint environment to dismiss them globally, or fix the code to
avoid them.

I'd therefore say that the cost of introducing Lint is about the same as
doing an extremely thorough code review and addressing all the issues found
in it. Something you should be doing anyway, just with Lint automating
some of the inspection!

The ROI starts immediately - Lint is a better reviewer than your
staff (it's a better reviewer than *anyone*'s staff), and the
incremental costs are low. And the journey becomes its own reward,
to some extent - you code knowing that it'll be Linted, and tend
not to do dodgy things.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas" HMHB


Re: PCLint experiences

:
:
: I'd like to know what people's experiences with PCLint from Gimpel are
: (or any other lint) for both C and C++ code.
<snip>

    It's never been useful trying to find a bug post mortem, in other words,
if your program does "this" it usually won't help you find what causes the
error.

    It will find alot of other bugs you didn't even know about.



Re: PCLint experiences
Quoted text here. Click to load it

PC-Lint V8 with MISRA-C checking is 145 UK Pounds (from www.hitex.co.uk)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ snipped-for-privacy@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Re: PCLint experiences
Quoted text here. Click to load it

...which is another thing it does better than expensive MISRA-only tools
from companies used to selling expensive bloatware into huge corporate
accounts. ;)

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas" HMHB


Re: PCLint experiences
Quoted text here. Click to load it

Almost infinitely.  Seriously. gcc -pedantic -Wall will catch a lot of
simple errors; Lint goes a *lot* deeper.

pete
--
snipped-for-privacy@fenelon.com "there's no room for enigmas in built-up areas" HMHB


Re: PCLint experiences
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

PClint, splint, and gcc all reveal slightly different things.  It
is up to you to evaluate their applicability to your code.  I tend
to run every new source file through splint.  If they can
conveniently be made clean it will be possible to sp/pclint the
whole system later without pain.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: PCLint experiences

[...]
Quoted text here. Click to load it

I dunno.  Compilers seem to be getting better at this game all the
time, but since I lint before I compile, I don't see many compiler
error messages.  

Take a look at http://www.gimpel.com/html/lintchks.htm to get an idea
of some of the checks that are made.  It might also be instructive to
look at http://www.gimpel.com/html/bugs.htm (the "Bug of the Month").
Some of these are C++-specific, but still interesting.

It's also nice that PC-lint will adapt to flukey compilers (like those
for the 8051) that use extended syntax (data, idata, xdata code,
interrupt, using, reentrant, etc.).  So you don't have to rely on your
compiler vendor to build good linting capabilities into their
compiler.  You can use a single tool across projects, compilers,
micros, etc.

I remember a version of MVSC (6.0?) that, when you enabled extra
warnings, would warn about

   extern void fn(unsigned char);
   ...
   fn(0);

because converting the integer constant zero to unsigned char might
lose the sign and some data bits.  I've always found PC-lint's
messages more useful than that.  And there's usually a way to clear
the message without resorting to an unnecessary cast...

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Site Timeline