Re: gcc -fanalyze

[Kamil Dudka]

On Tuesday, May 12, 2020 6:23:33 PM CEST Paul Eggert wrote:
> 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).

That is what we are doing already.  I am a developer of tools for filtering 
and comparing the warnings (csgrep and csdiff).  The problem is that such 
false positives may easily turn out into true positives, as the code gets 
changed, and nobody will notice it.

> 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,

It actually saves me work because it eases review of static analysis results.

> and also means you may have a different set of bugs than everyone
> else does (which means we all collectively lose out).

We can only have subset of the bugs that everyone else has.  I cannot image
a situation where initialization of otherwise uninitialized scalar variable 
could introduce a new bug.

> 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.

Yes but the uses of IF_LINT complicate detection of such programming mistakes.  
It may happen that a real bug disappears when the code is recompiled with
-Dlint, which is exactly the class of bugs that we are not going to have.

Kamil

> 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.