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
