Re: PCLint experiences

1. Lint is good.

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

Just my opinion.

Bruce

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

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

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

Excellent product.

All the time.

Some of the time.

Definitely recommended.

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

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

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

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

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.

In article , Ted Wood writes

PC-Lint V8 with MISRA-C checking is 145 UK Pounds (from

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

\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

pete

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

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

pete

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

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

[...]

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

to get an idea of some of the checks that are made. It might also be instructive to look at (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.