https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887

--- Comment #2 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643237.html has my notes
on things that need supporting, in <stdint.h>, <inttypes.h> and by implication
in printf and scanf, to support __int128 as an extended integer type for C23
and thus support int128_t, uint128_t, int_least128_t and uint_least128_t in
<stdint.h>.

I think we *should* add such support in GCC (thus, including GCC's <stdint.h>
for the freestanding case - header changes appropriately conditional on C23
mode) and glibc. Not of course in GCC 14 at the current development stage, as
it's clearly a new feature.

I think it should be done with an integer constant suffix (say i128 / I128 -
potentially confusing if used together with 'i' for complex integers, but not
ambiguous), rather than using wb/uwb together with the hack of making macros
expand to e.g. ((__int128) +123wb) to get the right type (the '+' together with
the cast, to a type name that's interpreted as 0 in the preprocessor, allows
such an expression to work in #if expressions as long as the value is within
the range of intmax_t which is all that's allowed there).

When adding such a feature to glibc we'd need to consider what user-visible
features are appropriate beyond the header changes and printf/scanf support.
That probably includes functions such as strotoi128 / wcstoi128 and the
unsigned and _l versions thereof (using C23 semantics unconditionally for 0b, I
suppose), maybe also i128abs, i128div. The type-generic macros in stdbit.h mean
we don't need extra type-specific functions there.

The default printf/scanf format checking in GCC is effectively for things that
are either standard or in glibc - and w128 is only standard when you have
support for int128_t and all the pieces that go along with that, at least on
the compiler side. (I'm supposing you don't want separate musl_printf format
checking support - although such a thing is possible, we do have separate
ms_printf support for Windows target.)

Reply via email to