Re: gcc -Wall vs. manywarnings

[Bruno Haible]

Paul Eggert wrote on 2023-05-27:
> If there are other ways to generate warnings to find bugs that are worth 
> the trouble of pacifying GCC, then it'd be helpful to use those ways 
> too. But plain 'gcc -Wall' is not one of those ways.
> ...
> I ... update the manywarnings module accordingly. This 
> process works well, for programs that use that module. It works better 
> than gcc -Wall does, in my experience.

OK, I took your word at face value, and changed GNU gettext to use
the manywarnings module. I care only about gcc 13, on a Linux/x86_64
system. Here are my findings:

* Actual bugs were found through these warning options:
  -Wanalyzer-null-dereference           (1)
  -Wanalyzer-possible-null-dereference  (1)
  -Wanalyzer-possible-null-argument     (3)
  -Wmissing-field-initializers          (1)
  -Wunused-macros                       (1)

* I can agree that "it works better than 'gcc -Wall'", in the sense
  that it found bugs that I had not spotted with merely "gcc -Wall".

* But I cannot agree that "it's not worth pacifying the warnings
  generated by 'gcc -Wall'", except for -Wsign-compare.
  'gcc -Wall' has the advantage that it is a good compromise and
  easy to use across packages.

* With more time investment, one gets more benefit. With just 'gcc -Wall',
  I didn't see the 7 bugs listed above, but I didn't have to spend much
  time learning about the various warnings.
  With the manywarnings module, I spent several days evaluating ca. 30
  different warning options. The benefit is that many more gcc warning
  options will be automatically enabled and thus useful in the future.

* 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 can be a random compiler if you use GCC the wrong way. If you use an 
> old version of GCC it might generate bogus diagnostics. Or if you 
> combine -Wall with some other options (-mx32, -Og, etc.) it might 
> generate bogus diagnostics. We shouldn't waste time pacifying gcc on 
> every possible platform with every possible set of options

I agree. In order to not waste time, we should better use new gcc versions
(or possibly also new clang versions?) to look at the diagnostics.

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

Therefore I consider '-Werror' a disservice, especially if it's used
with old versions of gcc and/or on not-so-relevant platforms.
It encourages users to report any remaining warning even on not-so-relevant
platforms.

> For programs like diffutils that use the manywarnings module, the best 
> way to generate warnings is to configure with --enable-gcc-warnings.

For GNU gettext, I chose to make things work a bit differently than in
diffutils, coreutils, grep, sed,
see 
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=m4/more-warnings.m4 
:
  * -Werror is not used (see above).
  * There is an option --enable-more-warnings, but hardly anyone will ever
    need to specify it explicitly, since specifying -Wall triggers
    --enable-more-warnings by default.
  * Compilations from a git checkout and compilations from a tarball
    behave the same way.

Bruno