On Wed, Jun 14, 2023, at 10:52 AM, Joseph Myers wrote: > On Tue, 13 Jun 2023, Paul Eggert wrote: > >> > There is always the possibility to have the header co-owned by both >> > the compiler and C library, limits.h style. Just >> > #if __has_include_next(<stdckdint.h>) >> > # include_next <stdckdint.h> >> > #endif >> >> I don't see how you could implement >> __has_include_next(<stdckdint.h>) for arbitrary non-GCC compilers, >> which is what we'd need for glibc users. For glibc internals we can >> use "#include_next" more readily, since we assume a new-enough GCC. >> I.e. we could do something like this: > > Given the possibility of library functions being included in > <stdckdint.h> in future standard versions, it seems important to look > at ways of splitting responsibility for the header between the > compiler and library, whether with __has_include_next, or compiler > version conditionals, or some other such variation.
limits.h is a horrible mess, with both the compiler and the library trying to get the last word, and I don't think we should take it as a model. I suggest a better model is GCC 12's stdint.h, where the compiler provides "stdint-gcc.h" that's used *only* in freestanding mode, and a wrapper header that defers to the C library (using #include_next, which is safe in GCC-provided headers) when __STDC_HOSTED__ is defined; meanwhile, glibc's stdint.h doesn't look for compiler-provided headers at all. In this case it sounds like glibc needs the compiler to provide some of the definitions, and I suggest this should be done via private predefined macros, in the mode of __INTx_TYPE__ and friends. zw
