On Wed, 17 Jan 2024, Jonathan Wakely wrote: > So we can remove the dependency on __STRICT_ISO__ for 128-bit integer > types, and implementing std::is_integral with a built-in seems like > the perfect time to do that. But that seems like stage 1 material, as > we need to go through the library and see what needs to change.
As noted on IRC, for C23 there would also be library issues in making __int128 an extended integer type. If it's an extended integer type, then C23 would require <stdint.h> to define int128_t, uint128_t, int_least128_t and uint_least128_t, along with the macros INT128_WIDTH, UINT128_WIDTH, INT_LEAST128_WIDTH, UINT_LEAST128_WIDTH (trivial), and INT128_C and UINT128_C (require an integer constant suffix), and INT128_MAX, INT128_MIN, UINT128_MAX, INT_LEAST128_MAX, INT_LEAST128_MIN, UINT_LEAST128_MAX (most simply defined using an integer constant suffix, though don't strictly require one). And <inttypes.h> would have to define all the printf and scanf format macros for int128_t, uint128_t, int_least128_t and uint_least128_t - so library support would be needed for those (the format macros themselves should probably expand to "w128d" and similar, a C23 feature already supported for narrower types by glibc and by GCC format checking, rather than inventing new features there). So because an extended integer type (without padding bits) in C23 is expected to have all the library support from <stdint.h> and <inttypes.h>, you need integer constant suffixes and printf/scanf support before you can declare __int128 an extended integer type for C23. (If adding printf and scanf support for int128_t to glibc, it probably makes sense to add user-visible functions such as strtoi128 at the same time - no such functions are in the standard, but something like them would be needed internally as part of the scanf implementation, and it's likely they would be useful for users as well.) -- Joseph S. Myers josmy...@redhat.com
