Bruno Haible <[EMAIL PROTECTED]> 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
