Hi Tim, > > 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. > > That is really bad and it makes me sad. You are saying it's a good thing > to get used to a bad situation. I hope you don't mean it.
Sorry but why do you call it "really bad", given that these warnings - are so few that the maintainer is not hindered in their development, - we know that these warnings are false positives? > > 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. > > ... the quality of Valgrind > depends on the code path coverage - that is not the same as code > coverage. To get the test data to cover most code paths you need a > fuzzer, at least for the more complex functions / functionality. Writing > good fuzzers takes time and sometimes need a lot of human time for > tuning. I did not say anything negative about fuzzying. Like you say, efforts on valgrind testing and efforts on fuzzying are complementary: With the fuzzying you increase the code coverage and code path coverage; with valgrind you check against undefined behaviour caused by uninitialized variables. > since there are > tests in glibc/gnulib for glob() that are also used with Valgrind, > aren't there ? We do have a problem with the valgrind integration into projects that use Automake: There's not one clearly best way to use valgrind that is documented, therefore every package maintainer spends time on a valgrind integration. Bruno
