bug-gnulib
[Top][All Lists]
Advanced

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

Re: gcc -fanalyze


From: Kamil Dudka
Subject: Re: gcc -fanalyze
Date: Tue, 12 May 2020 17:17:22 +0200

On Monday, May 11, 2020 7:26:34 PM CEST Paul Eggert wrote:
> On 5/11/20 12:43 AM, Kamil Dudka wrote:
> > It is usually bad idea to use different versions of source code for
> > compilers and for static analyzers.
> 
> Yes, I don't like it either. The patch I installed was particularly bad,
> since the workaround code was buggy. My only excuse is that the GCC bug
> itself is quite bad. Sometimes if your tools are bad it infects your own
> work....
> > There might be some exceptions where skipped initialization or cleanup
> > brings measurable speedup.  However in most of the cases the *_LINT
> > macros are just useless obfuscation of the source code.
> 
> This 100% backwards. The IF_LINT constructions are not primarily for
> performance. They are primarily so that one can do better static checking if
> one has good tools. If you have a good tool, you can arrange for IF_LINT(X)
> to be empty. If you have a tool that is not so good (GCC comes to mind :-),
> then you may can arrange for IF_LINT(X) to expand to X to prevent the
> less-capable tool from crying wolf.

Good tools exist in theory.  In practice the tool is either fast or precise.  
Following all possible code paths separately is just too expensive for tools 
like GCC.

> > I use the following patch in Fedora coreutils to make static analyzers see
> > the code that is actually going to run
> 
> This is also wrong. If you want static analyzers to see the code that is
> actually going to run, then you should build the software the same way for
> the static analyzers that you do for the running code.

Yes, that is exactly what we do at Red Hat.  Sorry if it was unclear from my 
statement.  We run static analyzers in the same environment where we build 
production RPM packages and the code is compiled with the same compiler flags.

The mentioned patch makes it possible because it reduces the false positive 
rate for multiple static analyzers (without the need for using different 
preprocessor flags for compilers and for static analyzers).

> This is elementary,
> and you have to do that anyway for all the other configuration flags you
> may use. IF_LINT is not special here.

Pádraig Brady suggested me to run static analyzers with -Dlint, which is 
exactly opposite of what you are saying, isn't it?

https://lists.gnu.org/archive/html/coreutils/2018-06/msg00110.html

Kamil

> We shouldn't get rid of the IF_LINT expressions, ugly as they are, because
> they tell us what the code would look like if we had better static analysis
> tools, and this is useful information to the human reader even when our
> tools are inadequate.





reply via email to

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