This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix -Wundef warnins for __FP_FAST_FMA*
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Tue, 18 Mar 2014 15:36:18 -0700 (PDT)
- Subject: Re: [PATCH] Fix -Wundef warnins for __FP_FAST_FMA*
- Authentication-results: sourceware.org; auth=none
- References: <20140318020544 dot GO1850 at spoyarek dot pnq dot redhat dot com> <5327CDCD dot 6030006 at redhat dot com> <20140318050711 dot GP1850 at spoyarek dot pnq dot redhat dot com> <5328510F dot 3050003 at redhat dot com>
Indeed installed headers and compiler predefines are importantly different
cases than most of what we want to clean up in this regard. Still, I think
we should be aiming for the same goal: minimize the possibility of typo
bugs not detected by -Wundef.
The context of installed headers just means that we have to take care with
the name space issues and the wide variety of older (and non-GNU) compilers
and their option combinations that might be in use, and beware of how users
might mistakenly misuse any internal macros we expose.
The context of predefines usually means that the base thing we're looking
at provided by the compiler has to be tested with #ifdef. (For any future
predefines, we should work with compiler folks to suggest that new things
follow the #if-friendly pattern of macros always defined to either 0 or 1
rather than the typo-prone pattern of sometimes-defined macros.) But that
doesn't mean there isn't cleanup and typo-proofing we should be doing. We
should make sure that each predefine is tested with #ifdef in exactly one
place. That place can then define internal macros to 0 or 1 so they can be
used elsewhere in our headers with #if and -Wundef. The one place might be
simply at the top of an installed header (if the need to test it is solely
within that file or others that already must #include it). It might be in
a new topical helper header (e.g. bits/foobar-options.h) if that seems to
make the most sense. It might be in some new consolidated place for
handling many such macros (e.g. bits/predefines.h), or perhaps directly in
features.h). I think we'll want to see all the variety of uses of such
macros in our installed headers before we decide. (That is, audit the
macro use more generally, not just the things popping out with -Wundef.)
In short, these are the difficult cases. I'd kind of figured we'd knock
out all the cases in private code before tackling the nontrivial installed
header cases.
Thanks,
Roland