[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Warning in spawn-pipe.c (create_pipe)
From: |
Bruno Haible |
Subject: |
Re: Warning in spawn-pipe.c (create_pipe) |
Date: |
Wed, 13 Dec 2017 23:24:37 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-101-generic; KDE/5.18.0; x86_64; ; ) |
Hi Tim,
> clang's warning:
>
> spawn-pipe.c:364:34: warning: variable 'child' may be uninitialized when
> used here [-Wconditional-uninitialized]
> register_slave_subprocess (child);
> ^~~~~
I agree with your analysis that without massive inlining or other propagation,
the compiler cannot know whether the previous call to
posix_spawnp (&child, ...)
will have initialized the variable 'child'.
So this class of warning is of the category "don't turn it on by default
if you want to have a warning-free build; but do turn it on occasionally
if you find that it detects real bugs in your code".
> That's why I vote for initializing 'child' to 0 as suggested below. It
> seems to be good programming practice.
No. Not for me.
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).
Bruno
[1] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html
- Warning in spawn-pipe.c (create_pipe), Tim Rühsen, 2017/12/13
- Re: Warning in spawn-pipe.c (create_pipe),
Bruno Haible <=
- Re: Warning in spawn-pipe.c (create_pipe), Eric Blake, 2017/12/13
- Re: Warning in spawn-pipe.c (create_pipe), Tim Rühsen, 2017/12/14
- Re: Warning in spawn-pipe.c (create_pipe), Bruno Haible, 2017/12/14
- Re: Warning in spawn-pipe.c (create_pipe), Tim Rühsen, 2017/12/15
- Re: Warning in spawn-pipe.c (create_pipe), Tim Rühsen, 2017/12/15
- Re: Warning in spawn-pipe.c (create_pipe), Bruno Haible, 2017/12/15
- Re: Warning in spawn-pipe.c (create_pipe), Tim Rühsen, 2017/12/15
- Re: Warning in spawn-pipe.c (create_pipe), Gisle Vanem, 2017/12/15
- Re: Warning in spawn-pipe.c (create_pipe), Tim Rühsen, 2017/12/15
- Re: Warning in spawn-pipe.c (create_pipe), Paul Eggert, 2017/12/15