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

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Hi Simon,
>
> What is the use of these macros gl_WARN_COMPLEMENT, gl_WARN_SUPPORTED?
> They are not documented, and you haven't said what they are good for.

I'm using them in some packages like this:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=configure.ac;h=c66cac2b4fb85b12ddf21b0d7fa676cd795319d9;hb=HEAD#l187
http://git.savannah.gnu.org/gitweb/?p=libidn.git;a=blob;f=configure.ac;h=d8b2d2d3b300d3f84930dd1f727d5c5338d1561a;hb=HEAD#l111
http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=blob;f=configure.ac;h=ecec2bfd9d1b3d1bf5983a63968c06ea6c0f1640;hb=HEAD#l60
http://git.savannah.gnu.org/gitweb/?p=gsasl.git;a=blob;f=configure.ac;h=abe3e5a51a43a71c082b2539dce76fe4ff370655;hb=HEAD#l86

I should add something to warnings.texi related this usage too.

> In particular, I don't see what anyone can do with the list of all
> GCC supported warning options.

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.

Admittedly, there are some warnings (e.g., -Wsystem-headers) that is
likely to always be removed.  Still, I prefer the approach to remove
from a assumed complete and centrally maintained list of warnings rather
than playing catch up in each project to try and add new variables as
they are introduced.

> While -Wall is widely applicable, most other warnings is specific to a
> particular kind of coding style or kind of application area. For
> example,
>  - -Wunused is useful when the program has no function types,
> but produces useless warnings when callbacks and function types are
> used,

I'm adding -Wno-unused-parameter to deal with that in GNU SASL and
GnuTLS.  Also, isn't there some gcc __attribute__ to mark unused
parameters if one really wanted to silence the -Wunused-parameter
warning?

Regarding -Wunused, I was unsure whether it needs to be added.  The GCC
4.3.2 manual appears contradicting on whether -Wunused is implied by
-Wall or not -- the documentation for -Wunused says it is implied by
-Wall, but the -Wunused variable (nor all of its components) are listed
under the documentation for -Wall.

So, in case -Wunused does anything that -Wall -Wextra doesn't also do, I
added it explicitly.  Maybe it could be removed after looking at GCC
code.  This may vary between GCC versions, too.

>   - -Wfloat-equal is useful when you write numerical approximation algorithms,
>     but produces useless warnings for implementations of basic functions like
>     ceill or roundl,

I haven't disabled this warning in any of my projects, so possibly when
someone adds code that trigger it, it will trigger a build failure,
which could help me study the code closer from this point of view as
well.  This is precisely my motivation for this effort, so it seems
fine.

>   - -Waggregate-return is useful for programs that want portability to
>     pre-ANSI-C compilers (!), but produces useless warnings for code that is
>     nowadays considered normal,

Sometimes it can help catch mistakes where you intended to return a
pointer to a big struct rather than the big struct itself.

>   - -Wlong-long is useful for programs that want portability to 1995 
> compilers,
>     but produces warnings for programs which require 64-bit integers (which
>     gnulib does).

Ouch -- the documented GnuTLS pre-requisite is ANSI C89 plus POSIX
recv/send.  It goes through some complexity to support 64-bit integers
even on platforms that doesn't have them.  We want to support embedded
platforms that doesn't have 64-bit integers (although merely passively
by accepting patches when problems are reported).

The code in gnulib that uses 'long long' seems to mostly be in *printf
functions, so we could comment out that code if it is required for
porting GnuTLS to a platform lacking 64-bit integers.

Still, adding code that assumes 64-bit integers to the GnuTLS code base
is something we would want to catch, so -Wlong-long seems useful.

This suggests it would be good to build the gnulib files in a project
with warning flags too, to catch when the gnulib code assumes more of
the system than the project does elsewhere.  I'll experiment if this is
realistic.

Thanks,
/Simon