My thoughts on PC-Lint Plus

I have been using Flexelint from Gimpel for many years and been quite happy with it. I started with version 8.00u in 2006, lots of patches/updates over the years, and finally used 9.0L. I have given a presentation about it at a conference and convinced my then-employer to buy a license too to improve software quality.

Then in 2016 Gimpel started producing a successor to Flexelint/PC-Lint based on clang, probably because parsing C++11 and C++17 can be quite tricky, and clang already does that. I was a beta-tester of PC-Lint Plus and it looked promising. Good backward compatibility with Flexelint 9.x, good support for newer C++ versions (Flexelint 9 only sort-of worked with C++04), and some new features I didn't have time to test. At the end of the beta test I would say it was near Flexelint 9.x in stability and features.

Then they released the new product and I saw the license agrement.

So as a consultant/contractor I cannot get a license to improve my work for clients because I don't own the code being analyzed. I cannot get a license which I can use on open-source projects, even my own (unless I buy a license for everyone that contributes to the project).

I have some sympathy for the license changes. I saw a rumour that a competitor had made a an unfair comparison, so that is probably the reason Gimpel doesn't want people (competitors) to publish the output unless for promoting PC-Lint Plus.

The old floating licenses probably also allowed some companies to get away with an unfair low number of licenses. But the result is that contractors and open-source developers cannot realisticly use PC-Lint Plus. And companies are in for a steep price increase.

I did not buy a license for PC-Lint Plus. Much later I heard rumours about the pricing which also give me pause.

For my C projects the old Flexelint 9.00L works fine. For C++ up to C++04 Flexelint 9.00L also works fine. For C++11 and beyond Flexelint doesn't work, and PC-Lint Plus is effectively unworkable for me.

Alternatives

There are no single good replacement. You can, however, use

There are also commercial alternatives:

All the commercial alternatives are expensive.

Post scriptum

I have been toying with the idea of making my own static analyzer based on Clang. What is holding me back is the amount of work before such a beast would be better than the already existing (weak) static analysis in Clang, and how much more to get it on par with eg. Flexelint 9. I don't see a way to recover that cost. I could also contribute to clang-analyzer, but what I really want is laser-precision warning suppression like in Flexelint, but that will probably take more gnashing of teeth than I'm willing to do. The compiler guys seem to think that by-file or by-block is enough, forcing me to resort to stuff like:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
…
#pragma clang diagnostic pop

to do a simple suppression of a single use of a deprecated API for instance, whereas in Flexelint you could simple do command-line/configuration-file -esym(586,some_deprecated_function), or a block-level //lint -e{586} or an in-line //lint -e586.