bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc -fanalyze


From: Paul Eggert
Subject: Re: gcc -fanalyze
Date: Tue, 12 May 2020 14:58:49 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/12/20 10:49 AM, Kamil Dudka wrote:

> The problem is that such 
> false positives may easily turn out into true positives, as the code gets 
> changed, and nobody will notice it.

Sounds extremely unlikely here. It's never happened with coreutils as far as I
know. For this particular case, this sounds more like a theoretical argument
than a practical one.
>> 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.

Why isn't it less work to build and analyze with '-Dlint'? Then you don't have
to change the source code, so you won't have to adapt your patch to future 
releases.

Is -Dlint avoided because it would break other tools? If so, how about if we
change coreutils's '#ifdef lint' to '#ifdef GCC_LINT'? Then you could build and
analyze with -DGCC_LINT. Emacs already does this, so there's good precedent.

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

I can. Perhaps the uninitialized variable has garbage in it that is typically
nonzero, and a later bug in the program is triggered only by a rare combination
of factors, one of which is that the variable must be zero.

Of course there's no such bug in coreutils - but there's no bug of the flavor
that you're imagining either. The point is that there's no proof that your bugs
are a subset of everyone else's in this area.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]