[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.
- Re: gcc -fanalyze, (continued)
- Re: gcc -fanalyze, Kamil Dudka, 2020/05/12
- Re: gcc -fanalyze, Paul Eggert, 2020/05/12
- Re: gcc -fanalyze, Kamil Dudka, 2020/05/12
- Re: gcc -fanalyze,
Paul Eggert <=
- Re: gcc -fanalyze, Kamil Dudka, 2020/05/13
- Re: gcc -fanalyze, Jeffrey Walton, 2020/05/13
- Re: reclaiming memory before exit, Bruno Haible, 2020/05/14
- Re: reclaiming memory before exit, Jeffrey Walton, 2020/05/14
- Re: reclaiming memory before exit, Paul Eggert, 2020/05/14
- Re: reclaiming memory before exit, Jeffrey Walton, 2020/05/15
- Re: reclaiming memory before exit, Kamil Dudka, 2020/05/15
- Re: reclaiming memory before exit, Bruno Haible, 2020/05/15
- Re: reclaiming memory before exit, Jeffrey Walton, 2020/05/15
- Re: reclaiming memory at dlclose time, Bruno Haible, 2020/05/15