Re: [PATCH] Fix -Wundef warnins for __FP_FAST_FMA*

["Carlos O'Donell" <carlos at redhat dot com>]

On 03/18/2014 06:36 PM, Roland McGrath wrote:
> 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.)

That makes sense.

> 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.

I have no preference, and I do not wish to impose any on those people wishing
to assist with this work. I think we can do them in almost any order, and still
win.

Cheers,
Carlos.