[Top][All Lists]

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

Re: [PATCH] fatal-signal: silence coverity warning

From: Eric Blake
Subject: Re: [PATCH] fatal-signal: silence coverity warning
Date: Fri, 29 Apr 2011 15:02:27 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9

On 04/29/2011 02:46 PM, Eric Blake wrote:
> On a glibc system, Coverity gives this warning:
> Error: UNINIT:
> m4-1.4.16/lib/fatal-signal.c:183: var_decl: Declaring variable "action" 
> without initializer.
> m4-1.4.16/lib/fatal-signal.c:198: uninit_use_in_call: Using uninitialized 
> value "action": field "action".sa_restorer is uninitialized when calling 
> "sigaction".

Hmm, I noticed that we already have other places in the code where we
are using #ifdef lint to do initializations that are needed only to
silence code analyzers (for example, see gl_linked_iterator in
gl_anylinked_list2.h).  Perhaps this sort of memset, or even constructs
like coreutils' IF_LINT macro, would be better for this particular line
of code.

Coreutils does

#ifdef lint
# define IF_LINT(Code) Code
# define IF_LINT(Code) /* */

> +++ b/lib/fatal-signal.c
> @@ -182,6 +182,7 @@ install_handlers ()
>    size_t i;
>    struct sigaction action;
> +  memset (&action, 0, sizeof action);

then for this, coreutils would have done:

struct sigaction action IF_LINT( = { 0 });

rather than adding a memset.

Which raises the question that we discussed a while ago - do we want to
add a macro into gnulib that is set according to whether we detect
compilation via a static analyzer tool, and which could automatically
behave like the #ifdef lint above?

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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