Static analysis tool?

Dave Nadler schrieb:

Hi Dave, in the (long gone) past I used a commercial tool called 'Lint' by a company caled 'Gimpel'. Its main problem is its extremely sharp eyes: It will tell you anything which might possibly be wrong - and you will be surprised how much of your code falls into this category. However, by way of a so called 'Lint file' you can configure Lint to suppress all kinds of warnings: If you say 'This is my coding style, and I know what I am doing' you can suppress many of the (for you) useless messages. I think I have heard of open source Lint programs but know nothing of the quality of their results. HTH Helmut

I haven't personally used it, but Frama-C is well regarded for this.

This isn't specifically about static analysis, but you might find it interesting:

Also, Dawson Engler's site

has lots of stuff about static analysis (he is the founder or a co-founder of Coverity).

Finally, ask yourself why you are still using C in this day and age at all, if correctness is critical. Ada, Rust, or even C++ can keep you out of a lot of trouble.

Am 16.04.2021 um 21:24 schrieb Dave Nadler:

First and foremost: if you've been sloppy for decades, throwing ANY tool at the existing codebase will bury you in "findings" and therefore not be useful. So, you WILL have to dumb down the tool to make it usable. If you're giving out big money for the tool, it'll be hard to predict whether you'll end up using 90% or 10% of it.

That aside, I consider the free tools good enough. The bang-for-the-buck ratio is hard to beat:

Recent gcc and clang versions learned to detect a lot of things that previously only specialized tools would find (e.g. switch/case fallthrough). Just turn on the bulk for a first test (-O2 -Wall

-Wextra), and turn on even more stuff later. For example, we're using

-Wconversion which can be really annoying but has found/would have found a few real bugs in our codebase. Of course this will bury you in warnings if you haven't tried it before.

cppcheck has the advantage of knowing some APIs, i.e. it will find some file descriptor leaks. On the downside, it has some annoying false positives (e.g. in C++11, it will flag every other method of a local class if one method is using std::move on a member).

Now I've also used Klocwork (which would be the same league as Coverity), but consider its gain minimal. In our codebase, it produces lots of false positives, some of which lead to sore forehead due to excessive facepalming. One annoying example is its attempt to implement the MISRA pseudo-type system, where '1

I uses PC_Lint Version 9, not the latest, but Gimple now only sell site licenses at rather high cost if you only need 1. It's still a cheapish solution. Ristan Case it nice but has not been updated for years and is not likely to be. Lint + MISRA is a bit like doing a code review with a colleague who objects to pretty much everything you do. For me its main virtue is in forcing you to think about stuff a little more. On the current project (where I'm using these tools) it has certainly caught a few bugs but a lot more instances of stuff that can (and should) be expressed more clearly or simply. The problem with working in a "MISRA compliant" environment is that slavish obedience is required which is often daft. The documentation burden of dealing with exceptions can become large.

On balance I think it improves my code. (And since on the current project no code reviews ever happen - it's all I've got :-(

All the above applies to C only.

MK

Your first step should always be the compiler - a good compiler, with optimisation enabled (that's essential) and lots of warnings will pick up many such things. It won't do everything, but it is certainly a good start. gcc in particular has got better and better at this over time - I have found bugs in code (other people's code, of course :-) ) after switching to a newer gcc and enabling more warnings.

Actually, that is perhaps the /second/ step. The first step is to adopt good coding practices (and perhaps a formal standard) that make it easier to avoid writing the bugs in the first place, and to spot them when they are made accidentally. For example, a strong emphasis on static inline functions rather than macros means your risk of macro problems drops dramatically - and a coding standard that insists on always guarding the arguments means you don't get the macro bug you mentioned above.

Thanks all for the comments. I should have explained this project came from elsewhere; landed in my lap to add a minor feature which resulted in needing to do lots of debug of existing problems. I even rewrote part of it in C++ ;-) Project is proprietary so Coverity scan is not applicable as that's only for FOSS. Only 5 (maybe 6?) of the top dozen bugs COULD be found by static analysis but certainly that would have been helpful.

If anybody has an hour and would be interested to review the presentation first draft video PM me - I can always use some constructive comments and suggestions!

Thanks again, Best Regards, Dave

Further follow-up: Never heard back from Coverity (as expected). Tried Perforce Klocworks and got a very perky and slightly less annoying sales person who promised prompt follow-up, and as usual none was forthcoming.

Any other static analysis tools you folks can suggest?