[OT] RE: Is there a free substitute for Flexilint?

[Kaz Kylheku]

gcc-help-owner@gcc.gnu.org wrote:
> Gimpel Software has a tool that I've gotten tons of benefit from when
> my employers have had a copy: FlexiLint.  It's been marvelous at
> statically checking C++ code and uncovered all kinds of evil bugs.
> 
> But it's also out-of-reach expensive: $1000 for a single user.

That's ``nothing'' for a software company. Even in an organization with,
say, 30 developers, you could keep the code clean with just one license
for this type of software. It's not the type of software that requires a
maintenance contract or upgrades. You buy it once and then ``lint away''
for years.

What's the cost of not doing the linting? Bugs caught late (i.e. by the
customer) can quickly eat away more than a thousand bucks from your
bottom line.

> Is there any free, or close-to-free, tool that you can recommend?

The GNU compiler has a lot of C++ specific warnings which are not turned
on by default. It's not exactly lint, but you can squeeze more out of
the compiler's diagnostic ability.

Flexelint requires a lot of tweaking. When you let it loose on a
codebase for the first time, it can produce a huge amount of noise. Not
all of it is useful. You'd be crazy to follow up on every one of its
recommendations by adjusting the code (rather than turning off the check
which produced it).

> (I suspect Valgrind has some overlap in terms of what bugs the two
> tools detect, but it's not going to catch stuff like misuse of
> "const", etc.)

There would only be overlap if you ignore the diagnostics from the
static checker and run the program anyway, under valgrind. :)

You can also get more out of valgrind by learning about its API. Misuse
of const /can/ actually be diagnosed. You see, you can inform Valgrind
that some arbitrary region of memory is read only. Then if anything
writes to it, there will be a diagnostic.

Of course, GCC doesn't have any code generation option to do this
valgrind-specific hack for const objects (but you could hack that
feature in!) Even the C front end can do this, because the
constructor/destructor hook mechanism is available to it. (The
bounds-checking patches for GCC that were developed years ago took
advantage of this in order to register and unregister block-scope
objects in the splay tree of live objects).