Re: [PATCH] warnings: Add gl_WARN_COMPLEMENT and gl_WARN_SUPPORTED.

[Bruno Haible]

Simon Josefsson wrote:
> I'm preparing a blog post about gcc warnings, but briefly my idea with
> warnings.m4 is to enable all possible warnings, build your project once
> with -Werror, disable the warnings that cause problems (using
> gl_WARN_COMPLEMENT), and set up so that the maintainer always build with
> -Werror plus the warning parameters.  This protects against introducing
> new code that triggers warning that weren't already triggered by the
> existing code base.

By doing this, in the end, the developer will have learned a lot about the
specific warning options of GCC, but hardly have fixed a real bug in the
code. Because, let me repeat it, most of these warnings don't point to *bugs*.
They point to a *coding style* different than the one that the warning wants
to enforce.

I agree that learning about the possible warnings that GCC offers and picking
the right set is something that every GNU project should do once.

But what I fear with your approach is:

  1) Many developers will try the warnings one by one, and often come to
     the same conclusions. For example, you noticed already:

     W="$W -Wsystem-headers"         # Don't let system headers trigger warnings
     W="$W -Wc++-compat"             # We don't care strongly about C++ 
compilers
     W="$W -Woverlength-strings"     # Some of our strings are too large
     W="$W -Wsign-conversion"        # Too many warnings for now
     W="$W -Wconversion"             # Too many warnings for now
     W="$W -Wtraditional"            # Warns on #elif which we use often
     W="$W -Wtraditional-conversion" # Too many warnings for now
     W="$W -Wmissing-noreturn"       # Too many warnings for now
     W="$W -Wunreachable-code"       # Too many false positives
     W="$W -Wlogical-op"             # Too many false positives

     It is a waste of time to let the gnulib users and the readers of your
     blog each try these warnings and come to the same conclusion.

  2) Some people will apply these warnings also to the gnulib part of their
     project, and report to gnulib the warnings. It will happen often that
     a warning option has not yet fired on the user's code but he sees it
     fire on gnulib code; so he will report it.
     But I don't want to hear about warnings that are about *style*. I do
     want to hear about warnings that indicate *bugs*. I invite people to
     report all warnings they see with "gcc -Wall". But if I have to reply
     to mails with reports about -Wunused or -Wconversion messages, it will
     take away my time.

I would find it much better if, rather than taking all possible warnings as a
starting point, you would recommend a reasonable set of warning options.

The reasonable set that I recommend is "-Wall".

Now that you have explained it, I see that while gl_WARN_ADD is generally
useful, gl_WARN_COMPLEMENT and gl_WARN_SUPPORTED are only useful for projects
which use your approach - which is not widely employed, since you want to
blog about it. I guess, 70% of the users will want to use gl_WARN_ADD, and
only 10% or 20% will want to adopt your approach. I therefore vote for moving
these two macros to a different gnulib module ('manywarnings'?) and
documenting them in a section of the manual after the one about the 'warnings'
module.

Btw, gl_WARN_SUPPORTED is a misnomer: it does not test whether the warnings
are supported; it's gl_WARN_ADD which does this. gl_WARN_ALL_GCC would be a
better name.

Bruno