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
signature.asc
Description: OpenPGP digital signature
