On 2020-10-01 15:46, Jonathan Wakely wrote:
> I hope WG14 will adopt something like
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2465.pdf and the
> whole mess will go away.
>
> intmax_t will be deprecated, and implementations can provide 128-bit
> integers without caveats.
On 2020-10-01 19:31, Joseph Myers wrote:
On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote:
Because 'intmax_t' has a bug
(actually I know GCC rejected the bug report,
but the problem is still there and users should be informed about this)
which is related to __int128.
__int128 is not an integer type as defined by any existing version of ISO
C, precisely because it's wider than intmax_t, and changing intmax_t would
be a big ABI problem (involving new symbol versions for about 100
printf/scanf-related functions in glibc, 200 on platforms with multiple
long double variants).
See the proposed removal of intmax_t in C2x (accepted in principle at the
first virtual Freiburg meeting, but so far without any wording accepted
for any specific approach to removal regarding e.g. preprocessor
arithmetic and other places depending on intmax_t). That removal would
allow __int128 to be considered an extended integer type as defined by C2x
and later (with int128_t typedef in <stdint.h>, etc.), if desired.
Thanks for pointing out that the standard acknowledges
the bug in [u]intmax_t. It's good to know.
Also good to know they plan to fix it.
Thanks,
Alex
