Re: Warning in spawn-pipe.c (create_pipe)

[Bruno Haible]

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