RFC: handling ISO C feature test macros

[Joseph Myers <joseph at codesourcery dot com>]

Various ISO C extensions / optional features have feature test macros that 
behave differently from those we currently support in GCC.

The various macros have inconsistencies I discussed in 
<http://www.open-std.org/jtc1/sc22/wg14/13016> regarding (a) whether they 
need to be consistent for separate #includes (something expressed in a way 
that can't actually be implemented without new compiler features, at least 
consistently with multiple include guards), (b) whether they are 0/1 
values, or undefined / defined, (c) what the rules are for the default if 
a macro is not defined.

The key difference from the currently supported macros, however, is that 
for the ISO C macros what matters is the definition when a *relevant* 
header is included - not any ISO C header, just a header affected by that 
macro (and there may or may not be rules about this needing to be the same 
for all includes of all headers affected by that macro).  This is 
inherently inconsistent with the glibc approach of including <features.h> 
from all system headers, and using that to define __USE_* just once.

I see two obvious approaches for handling the ISO macros in glibc:

(a) Test them directly where needed in headers.  For example, the 
issignaling definitions in math.h would be conditioned on:

#if defined __USE_GNU || defined __STDC_WANT_IEC_60559_BFP_EXT__

(_GNU_SOURCE should not cause __STDC_WANT_IEC_60559_BFP_EXT__ to be 
defined because the user might define it with a different expansion.  But 
in general we do want these features to be part of the GNU API, so implied 
by _GNU_SOURCE.)

(b) Add a header <features-iso.h>, which does not have a multiple include 
guard.  Relevant headers would include <features-iso.h> after 
<features.h>.  This header would take care of defining or undefining 
__USE_* based on the ISO macros, e.g.:

#undef __USE_IEC_60559_BFP_EXT
#if defined __USE_GNU || defined __STDC_WANT_IEC_60559_BFP_EXT__
# define __USE_IEC_60559_BFP_EXT 1
#endif

math.h would then just test __USE_IEC_60559_BFP_EXT for issignaling.  (Or 
it could have a shorter name, e.g. __USE_BFP_EXT.)

Any comments on the relative merits of the two approaches?

Whichever is chosen, I propose to implement it for the following feature 
test macros, for which we have some for the relevant functions/macros 
(only a very few, for the latter two macros, but I think it still makes 
sense to support the macros):

__STDC_WANT_LIB_EXT2__ (TR 24731-2:2010 - fmemopen, open_memstream etc.)
__STDC_WANT_IEC_60559_BFP_EXT__ (TS 18661-1:2014 - issignaling)
__STDC_WANT_IEC_60559_FUNCS_EXT__ (TS 18661-4:2015 - exp10f, exp10, exp10l)

-- 
Joseph S. Myers
joseph@codesourcery.com