[Top][All Lists]

[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).


[1] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html

reply via email to

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