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

[Paul Eggert <eggert@cs.ucla.edu>]

On 6/12/23 23:28, Jakub Jelinek via Libc-alpha wrote:
> On Mon, Jun 12, 2023 at 09:51:02PM +0000, Joseph Myers wrote:
>> On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote:
>>
>>> I have looked at gnulib stdckdint.h and they are full of workarounds
>>> for various compilers, EDG doesn't do this, clang <= 14 can't multiply
>>> __int128, ..., so I think the header belongs into the compiler rather
>>> than C library, because it would be a nightmare to maintain it there.

I tend to agree. I don't see how to implement <stdckdint.h> in the C 
library, at least not for the C library's users.

It would be possible to implement <stdckdint.h> for C library internal 
use only, because then we could assume #include_next, and we could use 
the Gnulib implementation safely (that implementation is already present 
glibc internals, just under a different name). This could well be worth 
doing, because glibc internally needs ckd_add (or something equivalent) 
but glibc can't yet assume that it's built with GCC 14 (or whatever GCC 
version eventually supports <stdckdint.h>).


> 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:

    #if 14 <= __GNUC__
    # include_next <stdckdint.h>
    #else
    # define ckd_add(r, a, b) INT_ADD_WRAPV (a, b, &(r))
    #endif

where INT_ADD_WRAPV is the already-existing glibc internal macro, and 
where we invoke ckd_add only with arguments free of side effects.