> On Aug 24, 2026, at 17:52, Dag-Erling Smørgrav <[email protected]> wrote: > > Warner Losh <[email protected]> writes: >> Dag-Erling Smørgrav <[email protected]> writes: >>> Shouldn't these be conditional on the visibility macros? >> Seems fine to me since it's in the implementation namespace. Maybe >> you could share your reasoning. > > Imagine a library which is is written to be backward compatible with C99 > but offers additional functionality which requires a C23 compiler and > uses one of these __STDC_VERSION_* macros to control its visibility in > the header. An application written in C99 uses this library and builds > with -std=c99. Because we set __STDC_VERSION_* unconditionally, the > library now exposes C23-only code to the C99 program, which therefore > fails to build. Therefore, these macros should only be defined if > __BSD_VISIBLE || __ISO_C_VISIBLE >= 2023.
Since these macros solely advertise which revision of the header our libc implements and are neither a language-mode nor visibility switch, I believe we’re fine. C23-only identifiers are already gated on our visibility macros, and exposure of these feature test macros per se are not of any harm, even for libraries targeting modes prior to C23. For the same very reason, it is also fine to have these as include guards (which brand new C23 headers like <stdbit.h> and <stdckdint.h> still do). My restoration of traditional guards was just to avoid any possible POLA violation for those depending on them (albeit wrong) as reported by dim for math/gmp port as an example. Cheers, Faraz
signature.asc
Description: Message signed with OpenPGP
