Re: gcc -Wall vs. manywarnings

[Paul Eggert]

On 2023-06-04 11:38, Bruno Haible wrote:

> * Evaluating warnings is one possible way to improve the quality of a
>    package. Alternatively, I could have spent the several days on a more
>    elaborate fuzzing approach, or on writing more unit tests, or on
>    improving the valgrind integration etc. — I can't say which is better,
>    since I cannot measure "quality".

It's indeed a judgment call. One argument for using manywarnings, from a 
security point of view, is that you can easily find all bugs that the 
black hats will find with the manywarnings, whereas you won't have that 
guarantee with new unit tests or fuzzing.


> (Why do coreutils, grep, gzip, sed enable the gcc warnings for gcc ≥ 4.6
> and not, say, only for gcc ≥ 10 ?)

Mostly those version checks simply document when those warnings were 
added to GCC. I vaguely recall some of the checks being put in back when 
some developers had 4.5 and some 4.6; if so, the checks were useful back 
then. Although I suppose we could change the checks to specify later GCC 
versions now, it hardly seems worth the effort unless the older version 
numbers cause trouble.


> Therefore I consider '-Werror' a disservice, especially if it's used
> with old versions of gcc and/or on not-so-relevant platforms.

Yes, and that's why -Werror is not enabled by default with coreutils 
etc., unless you're building as a developer in which case you should be 
using the latest tools anyway (and we tell potential developers that).


>    * Compilations from a git checkout and compilations from a tarball
>      behave the same way.

They can behave differently if the person checking out from git (or 
building from a tarball) has a different environment from the person who 
built the tarball. And to some extent this problem is unavoidable in our 
current build model: if you're building from git you need to be more of 
an expert, and we can expect more from experts. The only question is how 
much to expect.