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.
