This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

-Werror policy


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 
positives), use

#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
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]