This is the mail archive of the
mailing list for the glibc project.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Thu, 13 Nov 2014 23:43:35 +0000
- Subject: -Werror policy
- Authentication-results: sourceware.org; auth=none
I propose the following policy for use of -Werror in glibc builds.
* -Werror should be enabled by default. A --disable-werror configure
option should be available to disable it. This supersedes the existing
-Werror=implicit-function-declaration (we don't have warnings that stay
errors even with --disable-werror).
* The default enabling applies to all source files in glibc (testcases as
well as code that gets installed).
* When in the process of cleaning up a particular issue in glibc, we may
temporarily have -Wfoo -Wno-error=foo in the compilation options (so right
now, we'd have -Wno-error=undef).
* If a particular warning seems hard to fix (including hard-to-fix false
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wfoo"
#pragma GCC diagnostic pop
around the code generating the warning, with a comment stating the warning
and a GCC version / architecture for which it was observed. (In files
shared with gnulib, these pragma calls would need to be conditional.)
* If a particular source file has some issue globally (especially for code
imported from elsewhere), it may be OK to use a -Wno- option in the
makefiles, but for just a few warnings it's better to use the pragmas (and
it would be a good idea to transition existing -Wno- to use the pragmas).
In general it's even better to clean up the code, unless we want to keep
code from elsewhere unmodified or the code in question is a testcase and
the warnings are a consequence of something it's intended to test (if it's
testing how glibc handles a dubious construct that also gets warned about
at compile time, for example).
* We may start enabling -Werror by default based on getting a clean build
with the enabling patch for one architecture and compiler; the expectation
is that people testing with other architectures and compilers will then
fix issues they see.
Joseph S. Myers