bug-gnulib
[Top][All Lists]
Advanced

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

Re: Warning in spawn-pipe.c (create_pipe)


From: Eric Blake
Subject: Re: Warning in spawn-pipe.c (create_pipe)
Date: Wed, 13 Dec 2017 16:29:45 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 12/13/2017 04:24 PM, Bruno Haible wrote:

> 1) It is not a goal to have absolutely no warnings with GCC or
>    with clang. It is perfectly OK, IMO, if a compilation with "gcc -Wall"
>    shows, say, 5 warnings in 10 files. The maintainer will get used to
>    these warnings and see new warnings when they arise.
> 
> 2) For the problem of uninitialized variables that lead to undefined
>    behaviour, I don't see a GCC option that would warn about them [1].
>    Instead, 'valgrind' is the ultimate tool for detecting these kinds
>    of problems.
>    So if someone has a habit of looking only at GCC warnings, they should
>    change their habit and also use valgrind once in a while.
> 
> 3) Adding the 'child = 0' initialization has the effect that it will
>    silence both the clang warning and valgrind. However, if there is
>    a bug in the code that forgets to assign a value to the variable, the
>    bug will not be detected. In other words, the bug will still be present
>    but will be deterministic. => Such an initialization is a plus in
>    some situations (when debugging with gdb) and a minus in others.
> 
> Is '-Wconditional-uninitialized' implied in -Wall? If yes, I vote for
> adding '-Wno-conditional-uninitialized' at least for this specific file
> (through a Makefile.am variable).

Or through an in-file pragma that specifically documents that we are
intentionally ignoring the warning.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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