Configuration of this tool is a pain. The provided directions and supplemental files recommend using their provided ANSI-C-only header files, but those don't define enough stuff for the rest of the GNU libc headers to work. You need to point it at the compiler's header files (the path for which will change when the compiler gets upgraded). You also need to add to the set of predefined macros they recommend, because GCC 3.4.6 defines macros they don't supply, and GNU libc headers and the GCC headers depend on these macros.
I suspect the Windows version of the product may be better in this regard.
Using it via make is a bit annoying. A parallel set of rules for building "lint object files" akin to object files or libraries can be built pretty easily, but any "-L" and "-l" options seem to need to be converted to explicit references by pathname to the library description file.
It doesn't seem to understand "extern inline" very well, to the point that running flexelint on multiple source files together that each include <sys/stat.h> on Linux will generate warnings.
As with Sun lint, there are a lot of false positives relating to correlated variables (e.g., if var1 is nonzero, var2 has been allocated, and we test var1 before freeing var2), though I think not as many as Sun lint reports (with the particular options I was trying out).
Often when it warns about possible null pointer use, it includes "references" that point out other, earlier places where the variable in question is used; however, it's not always clear why the other location is mentioned. Sometimes it seems to be a use of the variable in a way that indicates the programmer thought maybe it could be null, and therefore at the use site it's possible; null pointer possibilities often don't seem to be examined unless the tool notices a null pointer can definitely be passed, or a test for a null pointer is performed.
Adding assertion tests can suppress some of the warnings, but gets into the question of how we want to handle can't-fail type situations in the code. In one approach, spreading assertion tests, with the understanding that they should be used only for cases where it is believed to be impossible for them to be tripped because of the way the code is structured, may be okay; other approaches may mandate that abort/exit never be called from library code, and if we ever test for these cases, we need to find a way to handle them should they come up.
Related to that is the question of checking for null pointers and correct magic numbers. If we stick in magic number tests, then analysis tools may correctly conclude that there are ways our "free" routines can fail to deallocate storage, for example, unless it's easily provable that the magic number has to be correct.
FlexeLint also seems to report conflicting structure types across source files for cases that seem fine to me.
It does do a good job of reporting certain kinds of cases of interest:
- functions or variables declared, but never defined
- macros declared in a source file and never used there
- assignment or comparison with different sizes or signedness
- pointer parameters that could be declared as pointing to const
- macro arguments with side effects being used multiple times
- header files included but unused
It also seems to be superior to Sun lint in terms of flexibility in annotation comments describing some semantics of functions. However, most of the supported semantics seem to be dealing with pointer arguments (must be non-null, may be null, must point to at least N objects) but not really describing pointed-to things (points to a pointer we fill in to "return" an object).
I don't recommend using the dataflow analysis aspects (of flexelint or Sun lint) heavily for Kerberos in the short term, unless we want to rework our code significantly to make the analysis easier; unfortunately, sometimes the APIs will make that difficult. Many of the other warnings and informational messages look useful.
The biggest thing in favor of flexelint/pclint is the Windows support, in a tool that can be run fairly quickly.
There is an online support forum, and people do seem responsive there.