* [RFC] man7/system_data_types.7: Document [unsigned] __int128
@ 2020-10-01 9:24 Alejandro Colomar
2020-10-01 9:57 ` Jonathan Wakely
0 siblings, 1 reply; 11+ messages in thread
From: Alejandro Colomar @ 2020-10-01 9:24 UTC (permalink / raw)
To: gcc; +Cc: Michael Kerrisk (man-pages), linux-man
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
]]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 9:24 [RFC] man7/system_data_types.7: Document [unsigned] __int128 Alejandro Colomar @ 2020-10-01 9:57 ` Jonathan Wakely 2020-10-01 10:14 ` Alejandro Colomar 0 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2020-10-01 9:57 UTC (permalink / raw) To: Alejandro Colomar; +Cc: gcc, linux-man, Michael Kerrisk (man-pages) 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 9:57 ` Jonathan Wakely @ 2020-10-01 10:14 ` Alejandro Colomar 2020-10-01 10:50 ` Jonathan Wakely ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Alejandro Colomar @ 2020-10-01 10:14 UTC (permalink / raw) To: Jonathan Wakely, gcc; +Cc: linux-man, Michael Kerrisk (man-pages) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 10:14 ` Alejandro Colomar @ 2020-10-01 10:50 ` Jonathan Wakely 2020-10-01 11:24 ` Alejandro Colomar 2020-10-01 12:54 ` Szabolcs Nagy 2020-10-01 17:31 ` Joseph Myers 2 siblings, 1 reply; 11+ messages in thread From: Jonathan Wakely @ 2020-10-01 10:50 UTC (permalink / raw) To: Alejandro Colomar; +Cc: gcc, linux-man, Michael Kerrisk (man-pages) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 10:50 ` Jonathan Wakely @ 2020-10-01 11:24 ` Alejandro Colomar 2020-10-01 11:46 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Alejandro Colomar @ 2020-10-01 11:24 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc, linux-man, Michael Kerrisk (man-pages) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 11:24 ` Alejandro Colomar @ 2020-10-01 11:46 ` Jonathan Wakely 0 siblings, 0 replies; 11+ messages in thread From: Jonathan Wakely @ 2020-10-01 11:46 UTC (permalink / raw) To: Alejandro Colomar; +Cc: gcc, linux-man, Michael Kerrisk (man-pages) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 10:14 ` Alejandro Colomar 2020-10-01 10:50 ` Jonathan Wakely @ 2020-10-01 12:54 ` Szabolcs Nagy 2020-10-01 13:22 ` Alejandro Colomar 2020-10-01 17:31 ` Joseph Myers 2 siblings, 1 reply; 11+ messages in thread From: Szabolcs Nagy @ 2020-10-01 12:54 UTC (permalink / raw) To: Alejandro Colomar Cc: Jonathan Wakely, gcc, linux-man, Michael Kerrisk (man-pages) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 12:54 ` Szabolcs Nagy @ 2020-10-01 13:22 ` Alejandro Colomar 2020-10-01 13:46 ` Jonathan Wakely 0 siblings, 1 reply; 11+ messages in thread From: Alejandro Colomar @ 2020-10-01 13:22 UTC (permalink / raw) To: Szabolcs Nagy, Jonathan Wakely Cc: gcc, linux-man, Michael Kerrisk (man-pages) 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. ]] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 13:22 ` Alejandro Colomar @ 2020-10-01 13:46 ` Jonathan Wakely 0 siblings, 0 replies; 11+ messages in thread From: Jonathan Wakely @ 2020-10-01 13:46 UTC (permalink / raw) To: Alejandro Colomar Cc: Szabolcs Nagy, gcc, linux-man, Michael Kerrisk (man-pages) 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 10:14 ` Alejandro Colomar 2020-10-01 10:50 ` Jonathan Wakely 2020-10-01 12:54 ` Szabolcs Nagy @ 2020-10-01 17:31 ` Joseph Myers 2020-10-02 8:10 ` Alejandro Colomar 2 siblings, 1 reply; 11+ messages in thread From: Joseph Myers @ 2020-10-01 17:31 UTC (permalink / raw) To: Alejandro Colomar Cc: Jonathan Wakely, gcc, linux-man, Michael Kerrisk (man-pages) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 2020-10-01 17:31 ` Joseph Myers @ 2020-10-02 8:10 ` Alejandro Colomar 0 siblings, 0 replies; 11+ messages in thread From: Alejandro Colomar @ 2020-10-02 8:10 UTC (permalink / raw) To: Joseph Myers; +Cc: Jonathan Wakely, gcc, linux-man, Michael Kerrisk (man-pages) 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-10-02 8:10 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-01 9:24 [RFC] man7/system_data_types.7: Document [unsigned] __int128 Alejandro Colomar 2020-10-01 9:57 ` Jonathan Wakely 2020-10-01 10:14 ` Alejandro Colomar 2020-10-01 10:50 ` Jonathan Wakely 2020-10-01 11:24 ` Alejandro Colomar 2020-10-01 11:46 ` Jonathan Wakely 2020-10-01 12:54 ` Szabolcs Nagy 2020-10-01 13:22 ` Alejandro Colomar 2020-10-01 13:46 ` Jonathan Wakely 2020-10-01 17:31 ` Joseph Myers 2020-10-02 8:10 ` Alejandro Colomar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).