Refining _DEFAULT_SOURCE and _GNU_SOURCE

[Joseph Myers]

On Mon, 1 Dec 2025, Florian Weimer via Gcc wrote:

> Sometimes, common identifiers are hidden by default behind macros like
> __STDC_WANT_IEC_60559_BFP_EXT__, for example iszero (if I read the
> sources correctly).  I assume the committee does not perform a
> compatibility impact analysis for those cases because they require an
> explicit opt-in.

iszero is conditioned on __GLIBC_USE (IEC_60559_BFP_EXT_C23).  As 
explained in bits/libc-header-start.h:

   __GLIBC_USE (IEC_60559_BFP_EXT_C23) controls those features from TS
   18661-1 that are also included in C23 (with no feature test macro
   required in C23).

__STDC_WANT_IEC_60559_BFP_EXT__ was the feature test macro from TS 18661-1 
(and a TS has a feature test macro because it's building on a previous 
standard version and the names mostly aren't reserved by that previous 
version).  Only a few TS 18661-1 functions still depend on a feature test 
macro in C23 (specifically, those defined in Annex F rather than the main 
standard).

> > If someone uses -std=c23 (thus, __STRICT_ANSI__ and no default 
> > _DEFAULT_SOURCE), of course they should get C23 library features as well 
> > as language features.  It would seem very odd for -std=gnu23 to provide 
> > fewer C23 library features than -std=c23, or for default -std=gnu23 to 
> > behave differently from explicit -std=gnu23.
> 
> That seems to rule out relying on any of the existing mechanisms.  The
> defaults may matter less (although the optics aren't great) than a way
> to go back in time if necessary.  Using -std=gnu17 does not have the
> intended effect for pure library additions.  I think you'd need a

So should there be a feature test macro meaning "don't default to enabling 
library features based on the language version"?  Or more specific 
negative feature test macros to override a default _ISOC23_SOURCE / 
_ISOC2Y_SOURCE based on the language version?

-- 
Joseph S. Myers
josmyers@redhat.com