Re: [RFC] Add stdckdint.h header for C23

["Zack Weinberg" <zack@owlfolio.org>]

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