[RFC] man7/system_data_types.7: Document [unsigned] __int128

[RFC] man7/system_data_types.7: Document [unsigned] __int128

[Alejandro Colomar]

Hi,

I'm documenting the system data types in the man-pages,
and I was writing now about these types.

I'm showing below both the rendered output and the source I have right now.

Would you add anything to it?

And I have some questions:

Is 'signed __int128' a valid thing,
and if so is it completely equivalent to '__int128'?

Is the GCC version correct?

There's no implementation where 'long long' is 128 bits yet, right?

Thanks,

Alex

Rendered output:
[[
__int128
       A signed integer type of a fixed width of exactly 128 bits.

       According to GNU, it is supported only for targets which have an
       integer mode wide enough to hold 128 bits.

       Bugs: It is not possible to express an integer constant of  type
       __int128  in  implementations  where  long long is less than 128
       bits wide.

       Conforming to: GCC 4.6.0 and later.

       Notes: This type is available without including any header.

       See also the intmax_t, intN_t and  unsigned  __int128  types  in
       this page.

[...]

unsigned __int128
       An unsigned integer type of a fixed width of exactly 128 bits.

       According to GNU, it is supported only for targets which have an
       integer mode wide enough to hold 128 bits.

       Bugs:  It is not possible to express an integer constant of type
       unsigned __int128 in implementations where unsigned long long is
       less than 128 bits wide.

       Conforming to: GCC 4.6.0 and later.

       Notes: This type is available without including any header.

       See also the __int128, uintmax_t and uintN_t types in this page.
]]

Source:
[[
.\"------------------------------------- __int128 ---------------------/
.TP
.I __int128
.RS
A signed integer type
of a fixed width of exactly 128 bits.
.PP
According to GNU,
it is supported only for targets which have
an integer mode wide enough to hold 128 bits.
.PP
Bugs:
It is not possible to express an integer constant of type
.I __int128
in implementations where
.I long long
is less than 128 bits wide.
.PP
Conforming to:
GCC 4.6.0 and later.
.PP
Notes:
This type is available without including any header.
.PP
See also the
.IR intmax_t ,
.IR int N _t
and
.I unsigned __int128
types in this page.
.RE

[...]

.\"------------------------------------- unsigned __int128 ------------/
.TP
.I unsigned __int128
.RS
An unsigned integer type
of a fixed width of exactly 128 bits.
.PP
According to GNU,
it is supported only for targets which have
an integer mode wide enough to hold 128 bits.
.PP
Bugs:
It is not possible to express an integer constant of type
.I unsigned __int128
in implementations where
.I unsigned long long
is less than 128 bits wide.
.PP
Conforming to:
GCC 4.6.0 and later.
.PP
Notes:
This type is available without including any header.
.PP
See also the
.IR __int128 ,
.I uintmax_t
and
.IR uint N _t
types in this page.
.RE
]]

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Jonathan Wakely]

On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> I'm documenting the system data types in the man-pages,
> and I was writing now about these types.
>
> I'm showing below both the rendered output and the source I have right now.
>
> Would you add anything to it?
>
> And I have some questions:
>
> Is 'signed __int128' a valid thing,
> and if so is it completely equivalent to '__int128'?

Yes.

> Is the GCC version correct?
>
> There's no implementation where 'long long' is 128 bits yet, right?

Right.

> Thanks,
>
> Alex
>
> Rendered output:
> [[
> __int128
>        A signed integer type of a fixed width of exactly 128 bits.
>
>        According to GNU, it is supported only for targets which have an
>        integer mode wide enough to hold 128 bits.

"According to GNU"? Should that be GCC?

The GNU project doesn't have anything to say about it.

Maybe just "When using GCC, it is supported only ..."


>
>        Bugs: It is not possible to express an integer constant of  type
>        __int128  in  implementations  where  long long is less than 128
>        bits wide.
>
>        Conforming to: GCC 4.6.0 and later.

It doesn't conform to anything, shouldn't this say "This type is a GNU
extension." or just "This type is an extension." ?

>
>        Notes: This type is available without including any header.
>
>        See also the intmax_t, intN_t and  unsigned  __int128  types  in
>        this page.

Why would this type refer to intmax_t?

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Alejandro Colomar]

Hi Jonathan,

On 2020-10-01 11:57, Jonathan Wakely wrote:
 > On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc 
<gcc@gcc.gnu.org> wrote:
 >>
 >> Hi,
 >>
 >> I'm documenting the system data types in the man-pages,
 >> and I was writing now about these types.
 >>
 >> I'm showing below both the rendered output and the source I have 
right now.
 >>
 >> Would you add anything to it?
 >>
 >> And I have some questions:
 >>
 >> Is 'signed __int128' a valid thing,
 >> and if so is it completely equivalent to '__int128'?
 >
 > Yes.
 >
 >> Is the GCC version correct?
 >>
 >> There's no implementation where 'long long' is 128 bits yet, right?
 >
 > Right.
 >
 >> Thanks,
 >>
 >> Alex
 >>
 >> Rendered output:
 >> [[
 >> __int128
 >>         A signed integer type of a fixed width of exactly 128 bits.
 >>
 >>         According to GNU, it is supported only for targets which have an
 >>         integer mode wide enough to hold 128 bits.
 >
 > "According to GNU"? Should that be GCC?
 >
 > The GNU project doesn't have anything to say about it.
 >
 > Maybe just "When using GCC, it is supported only ..."

Ok,  I thought that GCC is part of the GNU project, but I don't know how 
much...
I'll use "When using GCC," :)

 >
 >
 >>
 >>         Bugs: It is not possible to express an integer constant of  type
 >>         __int128  in  implementations  where  long long is less than 128
 >>         bits wide.
 >>
 >>         Conforming to: GCC 4.6.0 and later.
 >
 > It doesn't conform to anything, shouldn't this say "This type is a GNU
 > extension." or just "This type is an extension." ?

That's what I had first: "Conforming to: GCC extension"
Then I thought that I could include the version information,
so I changed it to that.

Maybe "GCC extension (since GCC 4.6.0)" would be better?

 >
 >>
 >>         Notes: This type is available without including any header.
 >>
 >>         See also the intmax_t, intN_t and  unsigned  __int128  types  in
 >>         this page.
 >
 > Why would this type refer to intmax_t?
 >

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.

Here is the rendered intmax_t:

intmax_t
       Include: <stdint.h>.  Alternatively, <inttypes.h>.

       A  signed  integer type capable of representing any value of any
       signed integer type supported by the implementation.   According
       to  the C language standard, it shall be capable of storing val-
       ues in the range [INTMAX_MIN, INTMAX_MAX].

       The macro INTMAX_C() expands its argument to an integer constant
       of type intmax_t.

       The  length  modifier  for  intmax_t  for  the printf(3) and the
       scanf(3) families of functions is j; resulting commonly  in  %jd
       or %ji for printing intmax_t values.

       Bugs:  intmax_t  is not large enough to represent values of type
       __int128 in implementations where __int128 is defined  and  long
       long is less than 128 bits wide.

       Conforming to: C99 and later; POSIX.1-2001 and later.

       See also the uintmax_t type in this page.


Thanks,

Alex

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Jonathan Wakely]

On Thu, 1 Oct 2020 at 11:14, Alejandro Colomar <colomar.6.4.3@gmail.com> wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 11:57, Jonathan Wakely wrote:
>  > On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc
> <gcc@gcc.gnu.org> wrote:
>  >>
>  >> Hi,
>  >>
>  >> I'm documenting the system data types in the man-pages,
>  >> and I was writing now about these types.
>  >>
>  >> I'm showing below both the rendered output and the source I have
> right now.
>  >>
>  >> Would you add anything to it?
>  >>
>  >> And I have some questions:
>  >>
>  >> Is 'signed __int128' a valid thing,
>  >> and if so is it completely equivalent to '__int128'?
>  >
>  > Yes.
>  >
>  >> Is the GCC version correct?
>  >>
>  >> There's no implementation where 'long long' is 128 bits yet, right?
>  >
>  > Right.
>  >
>  >> Thanks,
>  >>
>  >> Alex
>  >>
>  >> Rendered output:
>  >> [[
>  >> __int128
>  >>         A signed integer type of a fixed width of exactly 128 bits.
>  >>
>  >>         According to GNU, it is supported only for targets which have an
>  >>         integer mode wide enough to hold 128 bits.
>  >
>  > "According to GNU"? Should that be GCC?
>  >
>  > The GNU project doesn't have anything to say about it.
>  >
>  > Maybe just "When using GCC, it is supported only ..."
>
> Ok,  I thought that GCC is part of the GNU project, but I don't know how
> much...
> I'll use "When using GCC," :)

It is, but the GNU project is a large organisation, and has nothing to
say about non-standard types defined by GCC. Just because GCC is part
of a larger proejct, doesn't mean the entire project defines
something.

>  >
>  >
>  >>
>  >>         Bugs: It is not possible to express an integer constant of  type
>  >>         __int128  in  implementations  where  long long is less than 128
>  >>         bits wide.
>  >>
>  >>         Conforming to: GCC 4.6.0 and later.
>  >
>  > It doesn't conform to anything, shouldn't this say "This type is a GNU
>  > extension." or just "This type is an extension." ?
>
> That's what I had first: "Conforming to: GCC extension"
> Then I thought that I could include the version information,
> so I changed it to that.
>
> Maybe "GCC extension (since GCC 4.6.0)" would be better?

I don't think that information belongs in the Conforming To section at
all. The version that added the type is nothing to do with
conformance, because it's an extension and there is nothing to conform
to.

Look at 'man clock_gettime' for comparison. It has a VERSIONS section
and some individual constants are annotated with "(since Linux
2.6.12)". That seems more appropriate for annotating individual types
within this man page which are not universally available.




>  >
>  >>
>  >>         Notes: This type is available without including any header.
>  >>
>  >>         See also the intmax_t, intN_t and  unsigned  __int128  types  in
>  >>         this page.
>  >
>  > Why would this type refer to intmax_t?
>  >
>
> 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.
>
> Here is the rendered intmax_t:
>
> intmax_t
>        Include: <stdint.h>.  Alternatively, <inttypes.h>.
>
>        A  signed  integer type capable of representing any value of any
>        signed integer type supported by the implementation.   According
>        to  the C language standard, it shall be capable of storing val-
>        ues in the range [INTMAX_MIN, INTMAX_MAX].
>
>        The macro INTMAX_C() expands its argument to an integer constant
>        of type intmax_t.
>
>        The  length  modifier  for  intmax_t  for  the printf(3) and the
>        scanf(3) families of functions is j; resulting commonly  in  %jd
>        or %ji for printing intmax_t values.
>
>        Bugs:  intmax_t  is not large enough to represent values of type
>        __int128 in implementations where __int128 is defined  and  long
>        long is less than 128 bits wide.

OK, makes sense.

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Alejandro Colomar]

Hi Jonathan,

On 2020-10-01 12:50, Jonathan Wakely wrote:
>> Ok,  I thought that GCC is part of the GNU project, but I don't know how
>> much...
>> I'll use "When using GCC," :)
> 
> It is, but the GNU project is a large organisation, and has nothing to
> say about non-standard types defined by GCC. Just because GCC is part
> of a larger proejct, doesn't mean the entire project defines
> something.


Ok.
>>   >>         Conforming to: GCC 4.6.0 and later.
>>   >
>>   > It doesn't conform to anything, shouldn't this say "This type is a GNU
>>   > extension." or just "This type is an extension." ?
>>
>> That's what I had first: "Conforming to: GCC extension"
>> Then I thought that I could include the version information,
>> so I changed it to that.
>>
>> Maybe "GCC extension (since GCC 4.6.0)" would be better?
> 
> I don't think that information belongs in the Conforming To section at
> all. The version that added the type is nothing to do with
> conformance, because it's an extension and there is nothing to conform
> to.
> 
> Look at 'man clock_gettime' for comparison. It has a VERSIONS section
> and some individual constants are annotated with "(since Linux
> 2.6.12)". That seems more appropriate for annotating individual types
> within this man page which are not universally available.
> 


Thank you!

Updated:

[[
__int128
       A signed integer type of a fixed width of exactly 128 bits.

       When  using  GCC, it is supported only for targets which have an
       integer mode wide enough to hold 128 bits.

       Versions: GCC 4.6.0 and later.

       Conforming to: GCC extension.

       Notes: This type is available without including any header.

       Bugs: It is not possible to express an integer constant of  type
       __int128  in  implementations  where  long long is less than 128
       bits wide.

       See also the intmax_t, intN_t and  unsigned  __int128  types  in
       this page.
]]

Just one more thing:
Would you say "GCC extension" or "GNU extension"?

Thanks,

Alex

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Jonathan Wakely]

On Thu, 1 Oct 2020 at 12:24, Alejandro Colomar <colomar.6.4.3@gmail.com> wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 12:50, Jonathan Wakely wrote:
> >> Ok,  I thought that GCC is part of the GNU project, but I don't know how
> >> much...
> >> I'll use "When using GCC," :)
> >
> > It is, but the GNU project is a large organisation, and has nothing to
> > say about non-standard types defined by GCC. Just because GCC is part
> > of a larger proejct, doesn't mean the entire project defines
> > something.
>
>
> Ok.
> >>   >>         Conforming to: GCC 4.6.0 and later.
> >>   >
> >>   > It doesn't conform to anything, shouldn't this say "This type is a GNU
> >>   > extension." or just "This type is an extension." ?
> >>
> >> That's what I had first: "Conforming to: GCC extension"
> >> Then I thought that I could include the version information,
> >> so I changed it to that.
> >>
> >> Maybe "GCC extension (since GCC 4.6.0)" would be better?
> >
> > I don't think that information belongs in the Conforming To section at
> > all. The version that added the type is nothing to do with
> > conformance, because it's an extension and there is nothing to conform
> > to.
> >
> > Look at 'man clock_gettime' for comparison. It has a VERSIONS section
> > and some individual constants are annotated with "(since Linux
> > 2.6.12)". That seems more appropriate for annotating individual types
> > within this man page which are not universally available.
> >
>
>
> Thank you!
>
> Updated:
>
> [[
> __int128
>        A signed integer type of a fixed width of exactly 128 bits.
>
>        When  using  GCC, it is supported only for targets which have an
>        integer mode wide enough to hold 128 bits.

I'm not sure "integer mode" is useful here. It's barely useful in the
GCC docs (it's an internal implementation detail of GCC, so not very
useful for end users). Outside the context of the GCC manual it's even
less likely to mean anything to users of this documentation.

Maybe just "supported only for targets where the compiler is able to
generate efficient code for 128-bit arithmetic" or something like
that. Maybe somebody else can suggest something better.


>
>        Versions: GCC 4.6.0 and later.
>
>        Conforming to: GCC extension.
>
>        Notes: This type is available without including any header.
>
>        Bugs: It is not possible to express an integer constant of  type
>        __int128  in  implementations  where  long long is less than 128
>        bits wide.
>
>        See also the intmax_t, intN_t and  unsigned  __int128  types  in
>        this page.
> ]]
>
> Just one more thing:
> Would you say "GCC extension" or "GNU extension"?

Good question. It's not specific to GCC, because other compilers also
define it, so maybe neither is appropriate.

Maybe openpty(3) is a suitable example to use, it says "CONFORMING TO
These are BSD functions, present in glibc. They are not standardized
in POSIX."

So maybe something like "This is a non-standard extension, present in
GCC. It is not standardized in C or POSIX." Again, maybe somebody else
has a better suggestion.

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Szabolcs Nagy]

The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> Here is the rendered intmax_t:
> 
> intmax_t
>       Include: <stdint.h>.  Alternatively, <inttypes.h>.
> 
>       A  signed  integer type capable of representing any value of any
>       signed integer type supported by the implementation.   According
>       to  the C language standard, it shall be capable of storing val-
>       ues in the range [INTMAX_MIN, INTMAX_MAX].
> 
>       The macro INTMAX_C() expands its argument to an integer constant
>       of type intmax_t.
> 
>       The  length  modifier  for  intmax_t  for  the printf(3) and the
>       scanf(3) families of functions is j; resulting commonly  in  %jd
>       or %ji for printing intmax_t values.
> 
>       Bugs:  intmax_t  is not large enough to represent values of type
>       __int128 in implementations where __int128 is defined  and  long
>       long is less than 128 bits wide.

or __int128 is not an integer type.

integer types are either standard or extended.
and __int128 is neither because it can be
larger than intmax_t and stdint.h does not
provide the necessary macros for it.

> 
>       Conforming to: C99 and later; POSIX.1-2001 and later.
> 
>       See also the uintmax_t type in this page.

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Alejandro Colomar]

On 2020-10-01 14:54, Szabolcs Nagy wrote:
> The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
>> Here is the rendered intmax_t:
>>
>> intmax_t
>>        Include: <stdint.h>.  Alternatively, <inttypes.h>.
>>
>>        A  signed  integer type capable of representing any value of any
>>        signed integer type supported by the implementation.   According
>>        to  the C language standard, it shall be capable of storing val-
>>        ues in the range [INTMAX_MIN, INTMAX_MAX].
>>
>>        The macro INTMAX_C() expands its argument to an integer constant
>>        of type intmax_t.
>>
>>        The  length  modifier  for  intmax_t  for  the printf(3) and the
>>        scanf(3) families of functions is j; resulting commonly  in  %jd
>>        or %ji for printing intmax_t values.
>>
>>        Bugs:  intmax_t  is not large enough to represent values of type
>>        __int128 in implementations where __int128 is defined  and  long
>>        long is less than 128 bits wide.
> 
> or __int128 is not an integer type.
> 
> integer types are either standard or extended.
> and __int128 is neither because it can be
> larger than intmax_t and stdint.h does not
> provide the necessary macros for it.


Hi Szabolcs,

I know GCC decided to not call it an integer type, and call it instead a 
scalar type, just to conform with the standards, at the same time 
provide a 128 int, and at the same time, not have to change the ABI of 
intmax_t.

But it looks like an integer type,
and in almost any possible way, it acts like an integer type.

I could call '__int128' a signed _scalar_ type in the description, but 
that might confuse those who don't know these details.  Do you think it 
would be better to call it that way, or just keep the integer word? 
(Jonathan, I'd also like to know your thoughts on this, BTW).

However, I would still have that bug documented, because in the end, the 
information programmers need is exactly that, and they don't really care 
if GCC calls it one way or the other just to avoid technical issues with 
the standards, IMO.

Thanks,

Alex


BTW, the updated rendered version is like this right now:

[[
__int128
       [signed] __int128

       A signed integer type of a fixed width of exactly 128 bits.
// This could change to "signed scalar type", but...

       When  using GCC, it is supported only for targets where the com-
       piler is able to generate  efficient  code  for  128-bit  arith-
       metic".

       Versions: GCC 4.6.0 and later.

       Conforming to: This is a non-standard extension, present in GCC.
       It is not standardized by the C language standard nor POSIX.

       Notes: This type is available without including any header.

       Bugs: It is not possible to express an integer constant of  type
       __int128  in  implementations  where  long long is less than 128
       bits wide.

       See also the intmax_t, intN_t and  unsigned  __int128  types  in
       this page.

[...]

unsigned __int128
       An unsigned integer type of a fixed width of exactly 128 bits.
// This could change to "signed scalar type", but...

       According  to  GNU,  it  is supported only for targets where the
       compiler is able to generate efficient code for  128-bit  arith-
       metic".

       Versions: GCC 4.6.0 and later.

       Conforming to: This is a non-standard extension, present in GCC.
       It is not standardized by the C language standard nor POSIX.

       Notes: This type is available without including any header.

       Bugs: It is not possible to express an integer constant of  type
       unsigned __int128 in implementations where unsigned long long is
       less than 128 bits wide.

       See also the __int128, uintmax_t and uintN_t types in this page.
]]

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Jonathan Wakely]

On Thu, 1 Oct 2020 at 14:22, Alejandro Colomar <colomar.6.4.3@gmail.com> wrote:
>
>
>
> On 2020-10-01 14:54, Szabolcs Nagy wrote:
> > The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> >> Here is the rendered intmax_t:
> >>
> >> intmax_t
> >>        Include: <stdint.h>.  Alternatively, <inttypes.h>.
> >>
> >>        A  signed  integer type capable of representing any value of any
> >>        signed integer type supported by the implementation.   According
> >>        to  the C language standard, it shall be capable of storing val-
> >>        ues in the range [INTMAX_MIN, INTMAX_MAX].
> >>
> >>        The macro INTMAX_C() expands its argument to an integer constant
> >>        of type intmax_t.
> >>
> >>        The  length  modifier  for  intmax_t  for  the printf(3) and the
> >>        scanf(3) families of functions is j; resulting commonly  in  %jd
> >>        or %ji for printing intmax_t values.
> >>
> >>        Bugs:  intmax_t  is not large enough to represent values of type
> >>        __int128 in implementations where __int128 is defined  and  long
> >>        long is less than 128 bits wide.
> >
> > or __int128 is not an integer type.
> >
> > integer types are either standard or extended.
> > and __int128 is neither because it can be
> > larger than intmax_t and stdint.h does not
> > provide the necessary macros for it.
>
>
> Hi Szabolcs,
>
> I know GCC decided to not call it an integer type, and call it instead a
> scalar type, just to conform with the standards, at the same time
> provide a 128 int, and at the same time, not have to change the ABI of
> intmax_t.
>
> But it looks like an integer type,
> and in almost any possible way, it acts like an integer type.
>
> I could call '__int128' a signed _scalar_ type in the description, but
> that might confuse those who don't know these details.  Do you think it
> would be better to call it that way, or just keep the integer word?
> (Jonathan, I'd also like to know your thoughts on this, BTW).

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.

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128

[Alejandro Colomar]

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