Re: gcc -fanalyze

[Paul Eggert]

On 5/12/20 8:17 AM, Kamil Dudka wrote:
> Pádraig Brady suggested me to run static analyzers with -Dlint, which is 
> exactly opposite of what you are saying, isn't it?

That depends on how you're building. I am assuming that you want your static
analyzers to analyze the code that you're actually running. If so:

1. For each platform that you build, also run static analyzers with the same
configuration options that you build with.

2. --enable-gcc-warnings is a configuration option, so as a corollary to (1)
this option should be set (or not set) consistently for both static analyzers
and for production builds.

3. If you don't like false alarms from GCC or from other static analyzers,
filter them out (or get better analyzers...). You can filter in many different
ways (e.g., by comparing the warnings you got last time from the ones you got
this time).

4. Changing the source code merely to pacify false alarms from static analyzers
should be a last resort. Too often, it increases overall costs.

If that's what Pádraig was suggesting, then that's what I'm saying too.

I doubt whether it's a good idea to apply downstream patches that mean you are
running differently from everybody else. This is more maintenance work for you,
and also means you may have a different set of bugs than everyone else does
(which means we all collectively lose out). Although the bug set is miniscule
here (so far in this thread we have found no real bugs), the maintenance hassle
has already cost me a couple of hours, hours that could have been spent more
productively.

> When I read the code, I am asking myself different 
> questions:
> 
> * How did Paul ensure that the variable is initialized on all code paths?

I checked it by hand.

> * Will it work in all possible corner cases?

Yes.  (You can take my word for it. :-)

> * Does it still work as expected after change XY applied by someone else?

Not if the someone else screws up. But this can happen with any part of the
code; the IF_LINT parts are not special.

I think part of the culture clash here is that while Coverity etc. can be a good
match for middling-quality code, it can be a net minus for high-quality code.
(And I say this as a former developer of a Coverity-like tool; I'm a big fan of
static checking.) Let's not misuse these tools in areas where they increase
costs overall.