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: Mon, 11 May 2020 09:43:49 +0200

On Sunday, May 10, 2020 3:13:41 AM CEST Paul Eggert wrote:
> The first bug in that output:
> 
> cc1: warning: function may return address of local variable
> [-Wreturn-local-addr] lib/careadlinkat.c:73:8: note: declared here
>    73 |   char stack_buf[1024];
> 
>       |        ^~~~~~~~~
> 
> This is a false alarm. I installed the attached patch to pacify GCC (if you
> build with GCC_LINT).

It is usually bad idea to use different versions of source code for compilers
and for static analyzers.  Even if you are sure that the code is correct now,
such #ifdef constructions may prevent static analyzers from detecting real
programming mistakes when the code is changed later on.

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.

I use the following patch in Fedora coreutils to make static analyzers see
the code that is actually going to run while providing reasonable signal to
noise ratio:

https://src.fedoraproject.org/rpms/coreutils/blob/4a6bfcaa/f/coreutils-8.32-if-lint.patch

Kamil

> But perhaps I jumped the gun here - the workaround is reasonably awful, so
> perhaps it'd be better to disable -Wreturn-local-addr instead, at least for
> this compilation unit.
> 
> lib/diffseq.h:432:36: warning: 'bxbest' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>   432 |               part->ymid = bxybest - bxbest;
> 
>       |                            ~~~~~~~~^~~~~~~~
> 
> This false alarm is because the program was built without GCC_LINT being
> defined. If you build with -DGCC_LINT the false alarm should go away. (Maybe
> some others will go away too, at least careadlinkat is like this now....)
> This is what Emacs etc. do. Perhaps this should be moved to the
> manywarnings module?
> 
> Speaking of which, manywarnings.m4 should be updated for GCC 10, mostly for
> the -fanalyze warnings. I installed the second attached patch to do that.





reply via email to

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