gcc-help-owner@xxxxxxxxxxx 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).
