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 [email protected]
