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

[Alejandro Colomar via Gcc]

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: Fwd: Re: Registers used for exception handling on Linux/m68k?

[John Paul Adrian Glaubitz]

Hi Nathan!

On 9/29/20 7:58 PM, Nathan Sidwell wrote:
> On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote:
>>
>> I'm looking for an information regarding exception handling on Linux/m68k, 
>> in particular
>> I need to know what registers are used by the ABI in order to implement the 
>> functions
>> "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the 
>> M680x0 backend
>> in LLVM [1], [2].
> 
> I don;t know what those functions are, but from their names they seem to be 
> related to figuring out the exception object and type?

I think so. I'm not a compiler expert hence my questions :-).

> Do you understand the itanium ABI's unwinding mechanism --
> 1) follow stack to get to landing pad.
> 2) invoke landing pad to see if it wants to catch
> 3) if not, continue following stack
> 4) once we've found one to catch it, we need to unwind properly, which 
> involves invoking cleanups. and eventually getting to the catcher
> 
> invoking the landing pad means passing (a) an integer telling it what's 
> happening, and (b) a pointer to data.

This seems to be the data that I need. I just need to understand how that works.

>> I looked into the GCC source code to find the corresponding parts but I 
>> could only find
>> the macros prefixed with "EH_" [4] which I didn't fully understand.
> 
> Those are the bits you want.  one of those is the selector (0?) and the other 
> is the data pointer (1?).

OK. But aren't they passed through particular registers on m68k? Or is this 
something specific
to LLVM?

Thanks for the help!
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Jonathan Wakely via Gcc]

On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc  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 via Gcc]

Hi Jonathan,

On 2020-10-01 11:57, Jonathan Wakely wrote:
> On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc 
 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: .  Alternatively, .

  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

[PATCH 00/16] Fixes; Document remaining stdint.h types

[Alejandro Colomar via Gcc]

Hi Michael,

Here are a few fixes (including one removing .br),
and then the remaining stdint types.

Cheers,

Alex

Alejandro Colomar (16):
  malloc_get_state.3: ffix
  system_data_types.7: srcfix
  system_data_types.7: srcfix
  system_data_types.7: srcfix
  system_data_types.7: Add int_fastN_t family of types
  int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,
int_fastN_t.3: New links to system_data_types(7)
  system_data_types.7: Add uint_fastN_t family of types
  uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3,
uint_fastN_t.3: New links to system_data_types(7)
  system_data_types.7: Add int_leastN_t family of types
  int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3,
int_leastN_t.3: New links to system_data_types(7)
  system_data_types.7: Add uint_leastN_t family of types
  uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3,
uint_leastN_t.3: New links to system_data_types(7)
  system_data_types.7: Add 'intptr_t'
  intptr_t.3: New link to system_data_types(7)
  system_data_types.7: Add 'uintptr_t'
  uintptr_t.3: New link to system_data_types(7)

 man3/int_fast16_t.3  |   1 +
 man3/int_fast32_t.3  |   1 +
 man3/int_fast64_t.3  |   1 +
 man3/int_fast8_t.3   |   1 +
 man3/int_fastN_t.3   |   1 +
 man3/int_least16_t.3 |   1 +
 man3/int_least32_t.3 |   1 +
 man3/int_least64_t.3 |   1 +
 man3/int_least8_t.3  |   1 +
 man3/int_leastN_t.3  |   1 +
 man3/intptr_t.3  |   1 +
 man3/malloc_get_state.3  |   2 +-
 man3/uint_fast16_t.3 |   1 +
 man3/uint_fast32_t.3 |   1 +
 man3/uint_fast64_t.3 |   1 +
 man3/uint_fast8_t.3  |   1 +
 man3/uint_fastN_t.3  |   1 +
 man3/uint_least16_t.3|   1 +
 man3/uint_least32_t.3|   1 +
 man3/uint_least64_t.3|   1 +
 man3/uint_least8_t.3 |   1 +
 man3/uint_leastN_t.3 |   1 +
 man3/uintptr_t.3 |   1 +
 man7/system_data_types.7 | 590 ++-
 24 files changed, 540 insertions(+), 74 deletions(-)
 create mode 100644 man3/int_fast16_t.3
 create mode 100644 man3/int_fast32_t.3
 create mode 100644 man3/int_fast64_t.3
 create mode 100644 man3/int_fast8_t.3
 create mode 100644 man3/int_fastN_t.3
 create mode 100644 man3/int_least16_t.3
 create mode 100644 man3/int_least32_t.3
 create mode 100644 man3/int_least64_t.3
 create mode 100644 man3/int_least8_t.3
 create mode 100644 man3/int_leastN_t.3
 create mode 100644 man3/intptr_t.3
 create mode 100644 man3/uint_fast16_t.3
 create mode 100644 man3/uint_fast32_t.3
 create mode 100644 man3/uint_fast64_t.3
 create mode 100644 man3/uint_fast8_t.3
 create mode 100644 man3/uint_fastN_t.3
 create mode 100644 man3/uint_least16_t.3
 create mode 100644 man3/uint_least32_t.3
 create mode 100644 man3/uint_least64_t.3
 create mode 100644 man3/uint_least8_t.3
 create mode 100644 man3/uint_leastN_t.3
 create mode 100644 man3/uintptr_t.3

-- 
2.28.0

[PATCH 03/16] system_data_types.7: srcfix

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index a653a7b11..a099c0250 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -406,7 +406,10 @@ Include:
 Alternatively,
 .IR  .
 .PP
-.IR int8_t ", " int16_t ", " int32_t ", " int64_t
+.IR int8_t ,
+.IR int16_t ,
+.IR int32_t ,
+.I int64_t
 .PP
 A signed integer type
 of a fixed width of exactly N bits,
@@ -418,7 +421,8 @@ capable of storing values in the range
 substituting N by the appropriate number.
 .PP
 According to POSIX,
-.IR int8_t ", " int16_t
+.IR int8_t ,
+.IR int16_t
 and
 .I int32_t
 are required;
@@ -1299,7 +1303,10 @@ Include:
 Alternatively,
 .IR  .
 .PP
-.IR uint8_t ", " uint16_t ", " uint32_t ", " uint64_t
+.IR uint8_t ,
+.IR uint16_t ,
+.IR uint32_t ,
+.I uint64_t
 .PP
 An unsigned integer type
 of a fixed width of exactly N bits,
@@ -1310,7 +1317,8 @@ capable of storing values in the range [0,
 substituting N by the appropriate number.
 .PP
 According to POSIX,
-.IR uint8_t ", " uint16_t
+.IR uint8_t ,
+.IR uint16_t
 and
 .I uint32_t
 are required;
-- 
2.28.0

[PATCH 01/16] malloc_get_state.3: ffix

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/malloc_get_state.3 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man3/malloc_get_state.3 b/man3/malloc_get_state.3
index f94efccf4..57781fd6b 100644
--- a/man3/malloc_get_state.3
+++ b/man3/malloc_get_state.3
@@ -29,7 +29,7 @@ malloc_get_state, malloc_set_state \- record and restore 
state of malloc impleme
 .nf
 .B #include 
 .PP
-.BI "void* malloc_get_state(void);"
+.BI "void *malloc_get_state(void);"
 .PP
 .BI "int malloc_set_state(void *" state );
 .fi
-- 
2.28.0

[PATCH 02/16] system_data_types.7: srcfix

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 105 ++-
 1 file changed, 70 insertions(+), 35 deletions(-)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 9cf67ee6f..a653a7b11 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -71,7 +71,8 @@ struct aiocb {
 For further information about this structure, see
 .BR aio (7).
 .PP
-Conforming to: POSIX.1-2001 and later.
+Conforming to:
+POSIX.1-2001 and later.
 .PP
 See also:
 .BR aio_cancel (3),
@@ -102,7 +103,8 @@ It is the type of the value returned by the
 .BR div (3)
 function.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR div (3)
@@ -143,7 +145,8 @@ the type of
 .I double_t
 is implementation-defined.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also the
 .I float_t
@@ -161,7 +164,8 @@ This type represents the entire floating-point environment,
 including control modes and status flags; for further details, see
 .BR fenv (3).
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR fenv (3)
@@ -178,7 +182,8 @@ This type represents the floating-point status flags 
collectively;
 for further details see
 .BR fenv (3).
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR fenv (3)
@@ -195,7 +200,8 @@ Alternatively,
 .PP
 An object type used for streams.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR fclose (3),
@@ -243,7 +249,8 @@ the type of
 .I float_t
 is implementation-defined.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also the
 .I double_t
@@ -270,7 +277,8 @@ A type used to hold group IDs.
 According to POSIX,
 this shall be an integer type.
 .PP
-Conforming to: POSIX.1-2001 and later.
+Conforming to:
+POSIX.1-2001 and later.
 .PP
 See also:
 .BR chown (2),
@@ -299,7 +307,8 @@ this shall be an integer type that can be used to contain a
 or
 .IR gid_t .
 .PP
-Conforming to: POSIX.1-2001 and later.
+Conforming to:
+POSIX.1-2001 and later.
 .PP
 See also:
 .BR getpriority (2),
@@ -324,7 +333,8 @@ It is the type of the value returned by the
 .BR imaxdiv (3)
 function.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR imaxdiv (3)
@@ -379,7 +389,8 @@ is defined and
 .I long long
 is less than 128 bits wide.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also the
 .I uintmax_t
@@ -453,7 +464,8 @@ for scanning
 .I int8_t
 values.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also the
 .IR __int128 ,
@@ -505,7 +517,8 @@ Contains members related to the formatting of numeric 
values.
 In the "C" locale, its members have the values
 shown in the comments above.
 .PP
-Conforming to: C11 and later; POSIX.1-2001 and later.
+Conforming to:
+C11 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR setlocale (3),
@@ -532,7 +545,8 @@ It is the type of the value returned by the
 .BR ldiv (3)
 function.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR ldiv (3)
@@ -556,7 +570,8 @@ It is the type of the value returned by the
 .BR lldiv (3)
 function.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also:
 .BR lldiv (3)
@@ -591,7 +606,8 @@ where the width of
 is no greater than the width of the type
 .IR long .
 .PP
-Conforming to: POSIX.1-2001 and later.
+Conforming to:
+POSIX.1-2001 and later.
 .PP
 See also:
 .BR fork (2),
@@ -638,7 +654,8 @@ for printing
 .I ptrdiff_t
 values.
 .PP
-Conforming to: C99 and later; POSIX.1-2001 and later.
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
 .PP
 See also the
 .I size_t
@@ -666,7 +683,8 @@ typedef struct {
 .PP
 This is a structure type used in regular expression matching.
 .PP
-Conforming to: POSIX.1-2001 and later.
+Conforming to:
+POSIX.1-2001 and later.
 .PP
 See also:
 .BR regexec (3)
@@ -686,9 +704,11 @@ type or a
 .I ssize_t
 type.
 .PP
-Conforming to: POSIX.1-2001 and later.
+Conforming to:
+POSIX.1-2001 and later.
 .PP
-Notes: Prior to POSIX.1-2008, the type was capable of storing
+Notes:
+Prior to POSIX.1-2008, the type was capable of storing
 the largest value that can be stored in either an
 .I off_t
 type or a
@@ -731,7 +751,8 @@ struct sigevent {
 For further details about this type, see
 .BR sigevent (7).
 

[PATCH 04/16] system_data_types.7: srcfix

[Alejandro Colomar via Gcc]

We used .br to force a simple line break (with no extra blank line)
after the tag.

Recently, we added .RS/.RS, and .RS comes just after the tag,
and I realized by accident that .RS already forces a simple line break.

Therefore, .br is completely redundant here, and can be removed.

This way we get rid of "raw" *roff requests in this page.

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 34 --
 1 file changed, 34 deletions(-)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index a099c0250..a301c2309 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -52,7 +52,6 @@ system_data_types \- overview of system data types
 .TP
 .I aiocb
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -88,7 +87,6 @@ See also:
 .TP
 .I div_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -113,7 +111,6 @@ See also:
 .TP
 .I double_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -156,7 +153,6 @@ type in this page.
 .TP
 .I fenv_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -174,7 +170,6 @@ See also:
 .TP
 .I fexcept_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -192,7 +187,6 @@ See also:
 .TP
 .I FILE
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -217,7 +211,6 @@ See also:
 .TP
 .I float_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -260,7 +253,6 @@ type in this page.
 .TP
 .I gid_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -293,7 +285,6 @@ See also:
 .TP
 .I id_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -318,7 +309,6 @@ See also:
 .TP
 .I imaxdiv_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -343,7 +333,6 @@ See also:
 .TP
 .I intmax_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -400,7 +389,6 @@ type in this page.
 .TP
 .IR int N _t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -484,7 +472,6 @@ types in this page.
 .TP
 .I lconv
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -534,7 +521,6 @@ See also:
 .TP
 .I ldiv_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -559,7 +545,6 @@ See also:
 .TP
 .I lldiv_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -584,7 +569,6 @@ See also:
 .TP
 .I pid_t
 .RS
-.br
 Include
 .IR  .
 Alternatively,
@@ -631,7 +615,6 @@ See also:
 .TP
 .I ptrdiff_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -671,7 +654,6 @@ types in this page.
 .TP
 .I regmatch_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -697,7 +679,6 @@ See also:
 .TP
 .I regoff_t
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -731,7 +712,6 @@ types in this page.
 .TP
 .I sigevent
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -780,7 +760,6 @@ structure in this page.
 .TP
 .I siginfo_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -817,7 +796,6 @@ See also:
 .TP
 .I sigset_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -847,7 +825,6 @@ See also:
 .TP
 .I sigval
 .RS
-.br
 Include:
 .IR  .
 .PP
@@ -880,7 +857,6 @@ in this page.
 .TP
 .I size_t
 .RS
-.br
 Include:
 .I 
 or
@@ -981,7 +957,6 @@ types in this page.
 .TP
 .I ssize_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1052,7 +1027,6 @@ types in this page.
 .TP
 .I suseconds_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1080,7 +1054,6 @@ structure in this page.
 .TP
 .I time_t
 .RS
-.br
 Include:
 .I 
 or
@@ -1118,7 +1091,6 @@ See also:
 .TP
 .I timer_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1142,7 +1114,6 @@ See also:
 .TP
 .I timespec
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1177,7 +1148,6 @@ See also:
 .TP
 .I timeval
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1210,7 +1180,6 @@ See also:
 .TP
 .I uid_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1241,7 +1210,6 @@ See also:
 .TP
 .I uintmax_t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1297,7 +1265,6 @@ type in this page.
 .TP
 .IR uint N _t
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
@@ -1384,7 +1351,6 @@ types in this page.
 .TP
 .I va_list
 .RS
-.br
 Include:
 .IR  .
 Alternatively,
-- 
2.28.0

[PATCH 07/16] system_data_types.7: Add uint_fastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 79 
 1 file changed, 79 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 07de6417f..e3ebc2270 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -1282,6 +1282,85 @@ See also:
 .BR getpwnam (2),
 .BR credentials (7)
 .RE
+.\"- uint_fastN_t -/
+.TP
+.IR uint_fast N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR uint_fast8_t ,
+.IR uint_fast16_t ,
+.IR uint_fast32_t ,
+.I uint_fast64_t
+.PP
+The fastest unsigned integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range [0,
+.BR UINT_FAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR uint_fast N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIuFAST N,
+.BR PRIoFAST N,
+.BR PRIxFAST N
+and
+.BR PRIXFAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIuFAST32"
+or
+.B %"PRIxFAST32"
+for printing
+.I uint_fast32_t
+values.
+The length modifiers for the
+.IR uint_fast N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNuFAST N,
+.BR SCNoFAST N,
+.BR SCNxFAST N
+and
+.BR SCNXFAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNuFAST16"
+or
+.B %"SCNxFAST16"
+for scanning
+.I uint_fast16_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+Notes:
+Some of these types may be optimized for size
+instead of raw performance.
+.PP
+See also the
+.IR int_fast N _t ,
+.IR int_least N _t ,
+.IR int N _t ,
+.IR uint_least N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- uintmax_t /
 .TP
 .I uintmax_t
-- 
2.28.0

[PATCH 06/16] int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3, int_fastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/int_fast16_t.3 | 1 +
 man3/int_fast32_t.3 | 1 +
 man3/int_fast64_t.3 | 1 +
 man3/int_fast8_t.3  | 1 +
 man3/int_fastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/int_fast16_t.3
 create mode 100644 man3/int_fast32_t.3
 create mode 100644 man3/int_fast64_t.3
 create mode 100644 man3/int_fast8_t.3
 create mode 100644 man3/int_fastN_t.3

diff --git a/man3/int_fast16_t.3 b/man3/int_fast16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fast32_t.3 b/man3/int_fast32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fast64_t.3 b/man3/int_fast64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fast8_t.3 b/man3/int_fast8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fastN_t.3 b/man3/int_fastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 76 
 1 file changed, 76 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index a301c2309..07de6417f 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -329,6 +329,82 @@ C99 and later; POSIX.1-2001 and later.
 See also:
 .BR imaxdiv (3)
 .RE
+.\"- int_fastN_t --/
+.TP
+.IR int_fast N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR int_fast8_t ,
+.IR int_fast16_t ,
+.IR int_fast32_t ,
+.I int_fast64_t
+.PP
+The fastest signed integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range
+.RB [ INT_FAST N _MIN ,
+.BR INT_FAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR int_fast N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIdFAST N
+and
+.BR PRIiFAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIdFAST64"
+or
+.B %"PRIiFAST64"
+for printing
+.I int_fast64_t
+values.
+The length modifiers for the
+.IR int_fast N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNdFAST N
+and
+.BR SCNiFAST N,
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNdFAST8"
+or
+.B %"SCNiFAST8"
+for scanning
+.I int_fast8_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+Notes:
+Some of these types may be optimized for size
+instead of raw performance.
+.PP
+See also the
+.IR int_least N _t ,
+.IR int N _t ,
+.IR uint_fast N _t ,
+.IR uint_least N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- intmax_t -/
 .TP
 .I intmax_t
-- 
2.28.0

[PATCH 08/16] uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3, uint_fastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/uint_fast16_t.3 | 1 +
 man3/uint_fast32_t.3 | 1 +
 man3/uint_fast64_t.3 | 1 +
 man3/uint_fast8_t.3  | 1 +
 man3/uint_fastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/uint_fast16_t.3
 create mode 100644 man3/uint_fast32_t.3
 create mode 100644 man3/uint_fast64_t.3
 create mode 100644 man3/uint_fast8_t.3
 create mode 100644 man3/uint_fastN_t.3

diff --git a/man3/uint_fast16_t.3 b/man3/uint_fast16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fast32_t.3 b/man3/uint_fast32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fast64_t.3 b/man3/uint_fast64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fast8_t.3 b/man3/uint_fast8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fastN_t.3 b/man3/uint_fastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH 10/16] int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3, int_leastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/int_least16_t.3 | 1 +
 man3/int_least32_t.3 | 1 +
 man3/int_least64_t.3 | 1 +
 man3/int_least8_t.3  | 1 +
 man3/int_leastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/int_least16_t.3
 create mode 100644 man3/int_least32_t.3
 create mode 100644 man3/int_least64_t.3
 create mode 100644 man3/int_least8_t.3
 create mode 100644 man3/int_leastN_t.3

diff --git a/man3/int_least16_t.3 b/man3/int_least16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_least32_t.3 b/man3/int_least32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_least64_t.3 b/man3/int_least64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_least8_t.3 b/man3/int_least8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_leastN_t.3 b/man3/int_leastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_leastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH 09/16] system_data_types.7: Add int_leastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 72 
 1 file changed, 72 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e3ebc2270..0b8057087 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -405,6 +405,78 @@ and
 .IR uint N _t
 types in this page.
 .RE
+.\"- int_leastN_t -/
+.TP
+.IR int_least N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR int_least8_t ,
+.IR int_least16_t ,
+.IR int_least32_t ,
+.I int_least64_t
+.PP
+The narrowest signed integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range
+.RB [ INT_LEAST N _MIN ,
+.BR INT_LEAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR int_least N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIdLEAST N
+and
+.BR PRIiLEAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIdLEAST64"
+or
+.B %"PRIiLEAST64"
+for printing
+.I int_least64_t
+values.
+The length modifiers for the
+.IR int_least N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNdLEAST N
+and
+.BR SCNiLEAST N,
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNdLEAST8"
+or
+.B %"SCNiLEAST8"
+for scanning
+.I int_least8_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.IR int_fast N _t ,
+.IR int N _t ,
+.IR uint_fast N _t ,
+.IR uint_least N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- intmax_t -/
 .TP
 .I intmax_t
-- 
2.28.0

[PATCH 11/16] system_data_types.7: Add uint_leastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 75 
 1 file changed, 75 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 0b8057087..f768e87ba 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -1433,6 +1433,81 @@ and
 .IR uint N _t
 types in this page.
 .RE
+.\"- uint_leastN_t /
+.TP
+.IR uint_least N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR uint_least8_t ,
+.IR uint_least16_t ,
+.IR uint_least32_t ,
+.I uint_least64_t
+.PP
+The narrowest unsigned integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range [0,
+.BR UINT_LEAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR uint_least N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIuLEST N,
+.BR PRIoLEAST N,
+.BR PRIxLEAST N
+and
+.BR PRIXLEAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIuLEAST32"
+or
+.B %"PRIxLEAST32"
+for printing
+.I uint_least32_t
+values.
+The length modifiers for the
+.IR uint_least N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNuLEAST N,
+.BR SCNoLEAST N,
+.BR SCNxLEAST N
+and
+.BR SCNXLEAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNuLEAST16"
+or
+.B %"SCNxLEAST16"
+for scanning
+.I uint_least16_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.IR int_fast N _t ,
+.IR int_least N _t ,
+.IR int N _t ,
+.IR uint_fast N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- uintmax_t /
 .TP
 .I uintmax_t
-- 
2.28.0

[PATCH 13/16] system_data_types.7: Add 'intptr_t'

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 65 
 1 file changed, 65 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index f768e87ba..2632436ed 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -616,6 +616,71 @@ and
 .I unsigned __int128
 types in this page.
 .RE
+.\"- intptr_t -/
+.TP
+.I intptr_t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+A signed integer type
+such that any valid
+.RI ( "void *" )
+value can be converted to this type and back.
+According to the C language standard, it shall be
+capable of storing values in the range
+.RB [ INTPTR_MIN ,
+.BR INTPTR_MAX ].
+.PP
+The length modifier for
+.I intptr_t
+for the
+.BR printf (3)
+family of functions
+is expanded by the macros
+.B PRIdPTR
+and
+.B PRIiPTR
+(defined in
+.IR  );
+resulting commonly in
+.B %"PRIdPTR"
+or
+.B %"PRIiPTR"
+for printing
+.I intptr_t
+values.
+The length modifier for
+.I intptr_t
+for the
+.BR scanf (3)
+family of functions
+is expanded by the macros
+.B SCNdPTR
+and
+.B SCNiPTR,
+(defined in
+.IR  );
+resulting commonly in
+.B %"SCNdPTR"
+or
+.B %"SCNiPTR"
+for scanning
+.I intptr_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.I uintptr_t
+and
+.I void *
+.\" TODO: Document void *
+types in this page.
+.RE
 .\"- lconv /
 .TP
 .I lconv
-- 
2.28.0

[PATCH 12/16] uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3, uint_leastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/uint_least16_t.3 | 1 +
 man3/uint_least32_t.3 | 1 +
 man3/uint_least64_t.3 | 1 +
 man3/uint_least8_t.3  | 1 +
 man3/uint_leastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/uint_least16_t.3
 create mode 100644 man3/uint_least32_t.3
 create mode 100644 man3/uint_least64_t.3
 create mode 100644 man3/uint_least8_t.3
 create mode 100644 man3/uint_leastN_t.3

diff --git a/man3/uint_least16_t.3 b/man3/uint_least16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_least32_t.3 b/man3/uint_least32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_least64_t.3 b/man3/uint_least64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_least8_t.3 b/man3/uint_least8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_leastN_t.3 b/man3/uint_leastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_leastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH 14/16] intptr_t.3: New link to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/intptr_t.3 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 man3/intptr_t.3

diff --git a/man3/intptr_t.3 b/man3/intptr_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/intptr_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH 15/16] system_data_types.7: Add 'uintptr_t'

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 68 
 1 file changed, 68 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 2632436ed..8884d3e18 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -1714,6 +1714,74 @@ and
 .I unsigned __int128
 types in this page.
 .RE
+.\"- uintptr_t /
+.TP
+.I uintptr_t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+An unsigned integer type
+such that any valid
+.RI ( "void *" )
+value can be converted to this type and back.
+According to the C language standard, it shall be
+capable of storing values in the range [0,
+.BR UINTPTR_MAX ].
+.PP
+The length modifier for
+.I uintptr_t
+for the
+.BR printf (3)
+family of functions
+is expanded by the macros
+.BR PRIuPTR,
+.BR PRIoPTR,
+.B PRIxPTR
+and
+.B PRIXPTR
+(defined in
+.IR  );
+resulting commonly in
+.B %"PRIuPTR"
+or
+.B %"PRIxPTR"
+for printing
+.I uintptr_t
+values.
+The length modifier for
+.I uintptr_t
+for the
+.BR scanf (3)
+family of functions
+is expanded by the macros
+.BR SCNuPTR,
+.BR SCNoPTR,
+.B SCNxPTR
+and
+.B SCNXPTR
+(defined in
+.IR  );
+resulting commonly in
+.B %"SCNuPTR"
+or
+.B %"SCNxPTR"
+for scanning
+.I uintptr_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.I intptr_t
+and
+.I void *
+.\" TODO: Document void *
+types in this page.
+.RE
 .\"- va_list --/
 .TP
 .I va_list
-- 
2.28.0

[PATCH 16/16] uintptr_t.3: New link to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/uintptr_t.3 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 man3/uintptr_t.3

diff --git a/man3/uintptr_t.3 b/man3/uintptr_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uintptr_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

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

[Jonathan Wakely via Gcc]

On Thu, 1 Oct 2020 at 11:14, Alejandro Colomar  wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 11:57, Jonathan Wakely wrote:
>  > On Thu, 1 Oct 2020 at 10:26, Alejandro Colomar via Gcc
>  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: .  Alternatively, .
>
>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: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

[Jonathan Wakely via Gcc]

On Thu, 1 Oct 2020 at 11:25, Alejandro Colomar via Gcc  wrote:
>
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 76 
>  1 file changed, 76 insertions(+)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index a301c2309..07de6417f 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -329,6 +329,82 @@ C99 and later; POSIX.1-2001 and later.
>  See also:
>  .BR imaxdiv (3)
>  .RE
> +.\"- int_fastN_t --/
> +.TP
> +.IR int_fast N _t
> +.RS
> +Include:
> +.IR  .
> +Alternatively,
> +.IR  .
> +.PP
> +.IR int_fast8_t ,
> +.IR int_fast16_t ,
> +.IR int_fast32_t ,
> +.I int_fast64_t
> +.PP
> +The fastest signed integer type
> +of a width of at least N bits,
> +N being the value specified in its type name.
> +According to the C language standard, they shall be
> +capable of storing values in the range
> +.RB [ INT_FAST N _MIN ,
> +.BR INT_FAST N _MAX ],
> +substituting N by the appropriate number.
> +.PP
> +The length modifiers for the
> +.IR int_fast N _t
> +types for the
> +.BR printf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR PRIdFAST N
> +and
> +.BR PRIiFAST N
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"PRIdFAST64"
> +or
> +.B %"PRIiFAST64"
> +for printing
> +.I int_fast64_t
> +values.
> +The length modifiers for the
> +.IR int_fast N _t
> +types for the
> +.BR scanf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR SCNdFAST N
> +and
> +.BR SCNiFAST N,
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"SCNdFAST8"
> +or
> +.B %"SCNiFAST8"
> +for scanning
> +.I int_fast8_t
> +values.
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +Notes:
> +Some of these types may be optimized for size
> +instead of raw performance.

I'm not sure what this tells me as a programmer. What does "raw
performance" means exactly? The text above says it's "the fastest",
but then it says "may be optimized for size". I don't know how to
interpret this. Is it fast or is it small, or something else? Is it
optimized for small size? Natural word size? Cacheline size?

I prefer the phrasing of the caveats in the C and POSIX standards
which just say it might not be fastest for all purposes.

How about "Where there is no single type that is fastest for all
purposes, the implementation may choose any type with the required
signedness and at least the minimum width."

I don't see anything in this man page saying that the  types
are all typedefs, rather than new types that are distinct from the
standard integer types. That seems like useful information.

Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

[Alejandro Colomar via Gcc]

On 2020-10-01 13:07, Jonathan Wakely wrote:
[...]

+Notes:
+Some of these types may be optimized for size
+instead of raw performance.


I'm not sure what this tells me as a programmer. What does "raw
performance" means exactly? The text above says it's "the fastest",
but then it says "may be optimized for size". I don't know how to
interpret this. Is it fast or is it small, or something else? Is it
optimized for small size? Natural word size? Cacheline size?

I prefer the phrasing of the caveats in the C and POSIX standards
which just say it might not be fastest for all purposes.

How about "Where there is no single type that is fastest for all
purposes, the implementation may choose any type with the required
signedness and at least the minimum width."

I don't see anything in this man page saying that the  types
are all typedefs, rather than new types that are distinct from the
standard integer types. That seems like useful information.



Hi Jonathan,

I wasn't sure about how to word it.

In theory, they should be the fastest types; just that.
But then, for some reason, GCC decided that
int_fast8_t should be int8_t instead of int64_t,
because when using arrays of int_fast8_t,
it will create smaller arrays, which will be faster (less cache, etc.).

(I remember having read that a long time ago, but I don't remember the 
source, or if it's the actual reason).


How would you word that?

Thanks,

Alex

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

[Alejandro Colomar via Gcc]

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: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

[Jonathan Wakely via Gcc]

On Thu, 1 Oct 2020 at 12:15, Alejandro Colomar  wrote:
>
>
>
> On 2020-10-01 13:07, Jonathan Wakely wrote:
> [...]
> >> +Notes:
> >> +Some of these types may be optimized for size
> >> +instead of raw performance.
> >
> > I'm not sure what this tells me as a programmer. What does "raw
> > performance" means exactly? The text above says it's "the fastest",
> > but then it says "may be optimized for size". I don't know how to
> > interpret this. Is it fast or is it small, or something else? Is it
> > optimized for small size? Natural word size? Cacheline size?
> >
> > I prefer the phrasing of the caveats in the C and POSIX standards
> > which just say it might not be fastest for all purposes.
> >
> > How about "Where there is no single type that is fastest for all
> > purposes, the implementation may choose any type with the required
> > signedness and at least the minimum width."
> >
> > I don't see anything in this man page saying that the  types
> > are all typedefs, rather than new types that are distinct from the
> > standard integer types. That seems like useful information.
> >
>
> Hi Jonathan,
>
> I wasn't sure about how to word it.
>
> In theory, they should be the fastest types; just that.
> But then, for some reason, GCC decided that
> int_fast8_t should be int8_t instead of int64_t,
> because when using arrays of int_fast8_t,
> it will create smaller arrays, which will be faster (less cache, etc.).
>
> (I remember having read that a long time ago, but I don't remember the
> source, or if it's the actual reason).

So then that's still optimized for "raw performance", isn't it? The
"raw performance" of copying an array of bytes is better than the "raw
performance" of copying an array of 64-bit types. The meaning of "raw
performance" depends on what you're doing, so I don't think it's a
useful term without context.

> How would you word that?

I gave a suggestion above.

Don't use terms like "raw performance" that are meaningless without
context. Using "no single type that is fastest for all purposes" makes
it clearer that "fastest" isn't something universally true, it might
be fastest for some purposes and not others.

Re: [PATCH 00/16] Fixes; Document remaining stdint.h types

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Hi Michael,
> 
> Here are a few fixes (including one removing .br),
> and then the remaining stdint types.

These very long patch series are a bit overwhelming for me.
I'd have preferred a few smaller patch series. For example, 
I think I would have preferred 3 series like this:

1-4
5-12
13-16

One reason is that the multiple parallel reply threads that 
sometimes occur can sometimes be rather difficult to track.
(Your patches have started some quite useful conversations!)

For example, I suspect Jonathan's comments may trigger changes
for patches 5-12.

For now, I'm applying 1-4 and 13-16. It looks like some reworking is
going to be needed for the others. When you do resubmit them, please
start a new thread (rather than replying into this thread).

Thanks,

Michael

> Alejandro Colomar (16):
>   malloc_get_state.3: ffix
>   system_data_types.7: srcfix
>   system_data_types.7: srcfix
>   system_data_types.7: srcfix
>   system_data_types.7: Add int_fastN_t family of types
>   int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,
> int_fastN_t.3: New links to system_data_types(7)
>   system_data_types.7: Add uint_fastN_t family of types
>   uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3,
> uint_fastN_t.3: New links to system_data_types(7)
>   system_data_types.7: Add int_leastN_t family of types
>   int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3,
> int_leastN_t.3: New links to system_data_types(7)
>   system_data_types.7: Add uint_leastN_t family of types
>   uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3,
> uint_leastN_t.3: New links to system_data_types(7)
>   system_data_types.7: Add 'intptr_t'
>   intptr_t.3: New link to system_data_types(7)
>   system_data_types.7: Add 'uintptr_t'
>   uintptr_t.3: New link to system_data_types(7)
> 
>  man3/int_fast16_t.3  |   1 +
>  man3/int_fast32_t.3  |   1 +
>  man3/int_fast64_t.3  |   1 +
>  man3/int_fast8_t.3   |   1 +
>  man3/int_fastN_t.3   |   1 +
>  man3/int_least16_t.3 |   1 +
>  man3/int_least32_t.3 |   1 +
>  man3/int_least64_t.3 |   1 +
>  man3/int_least8_t.3  |   1 +
>  man3/int_leastN_t.3  |   1 +
>  man3/intptr_t.3  |   1 +
>  man3/malloc_get_state.3  |   2 +-
>  man3/uint_fast16_t.3 |   1 +
>  man3/uint_fast32_t.3 |   1 +
>  man3/uint_fast64_t.3 |   1 +
>  man3/uint_fast8_t.3  |   1 +
>  man3/uint_fastN_t.3  |   1 +
>  man3/uint_least16_t.3|   1 +
>  man3/uint_least32_t.3|   1 +
>  man3/uint_least64_t.3|   1 +
>  man3/uint_least8_t.3 |   1 +
>  man3/uint_leastN_t.3 |   1 +
>  man3/uintptr_t.3 |   1 +
>  man7/system_data_types.7 | 590 ++-
>  24 files changed, 540 insertions(+), 74 deletions(-)
>  create mode 100644 man3/int_fast16_t.3
>  create mode 100644 man3/int_fast32_t.3
>  create mode 100644 man3/int_fast64_t.3
>  create mode 100644 man3/int_fast8_t.3
>  create mode 100644 man3/int_fastN_t.3
>  create mode 100644 man3/int_least16_t.3
>  create mode 100644 man3/int_least32_t.3
>  create mode 100644 man3/int_least64_t.3
>  create mode 100644 man3/int_least8_t.3
>  create mode 100644 man3/int_leastN_t.3
>  create mode 100644 man3/intptr_t.3
>  create mode 100644 man3/uint_fast16_t.3
>  create mode 100644 man3/uint_fast32_t.3
>  create mode 100644 man3/uint_fast64_t.3
>  create mode 100644 man3/uint_fast8_t.3
>  create mode 100644 man3/uint_fastN_t.3
>  create mode 100644 man3/uint_least16_t.3
>  create mode 100644 man3/uint_least32_t.3
>  create mode 100644 man3/uint_least64_t.3
>  create mode 100644 man3/uint_least8_t.3
>  create mode 100644 man3/uint_leastN_t.3
>  create mode 100644 man3/uintptr_t.3
> 
H

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 01/16] malloc_get_state.3: ffix

[Michael Kerrisk (man-pages) via Gcc]

Applied.

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/malloc_get_state.3 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/man3/malloc_get_state.3 b/man3/malloc_get_state.3
> index f94efccf4..57781fd6b 100644
> --- a/man3/malloc_get_state.3
> +++ b/man3/malloc_get_state.3
> @@ -29,7 +29,7 @@ malloc_get_state, malloc_set_state \- record and restore 
> state of malloc impleme
>  .nf
>  .B #include 
>  .PP
> -.BI "void* malloc_get_state(void);"
> +.BI "void *malloc_get_state(void);"
>  .PP
>  .BI "int malloc_set_state(void *" state );
>  .fi
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 02/16] system_data_types.7: srcfix

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 

I don't mind applying this patch (and I have done so),
but I think patches like this need a brief commit message 
to explain why you are making the change.

Thanks,

Michael

> ---
>  man7/system_data_types.7 | 105 ++-
>  1 file changed, 70 insertions(+), 35 deletions(-)
> 
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index 9cf67ee6f..a653a7b11 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -71,7 +71,8 @@ struct aiocb {
>  For further information about this structure, see
>  .BR aio (7).
>  .PP
> -Conforming to: POSIX.1-2001 and later.
> +Conforming to:
> +POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR aio_cancel (3),
> @@ -102,7 +103,8 @@ It is the type of the value returned by the
>  .BR div (3)
>  function.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR div (3)
> @@ -143,7 +145,8 @@ the type of
>  .I double_t
>  is implementation-defined.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also the
>  .I float_t
> @@ -161,7 +164,8 @@ This type represents the entire floating-point 
> environment,
>  including control modes and status flags; for further details, see
>  .BR fenv (3).
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR fenv (3)
> @@ -178,7 +182,8 @@ This type represents the floating-point status flags 
> collectively;
>  for further details see
>  .BR fenv (3).
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR fenv (3)
> @@ -195,7 +200,8 @@ Alternatively,
>  .PP
>  An object type used for streams.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR fclose (3),
> @@ -243,7 +249,8 @@ the type of
>  .I float_t
>  is implementation-defined.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also the
>  .I double_t
> @@ -270,7 +277,8 @@ A type used to hold group IDs.
>  According to POSIX,
>  this shall be an integer type.
>  .PP
> -Conforming to: POSIX.1-2001 and later.
> +Conforming to:
> +POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR chown (2),
> @@ -299,7 +307,8 @@ this shall be an integer type that can be used to contain 
> a
>  or
>  .IR gid_t .
>  .PP
> -Conforming to: POSIX.1-2001 and later.
> +Conforming to:
> +POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR getpriority (2),
> @@ -324,7 +333,8 @@ It is the type of the value returned by the
>  .BR imaxdiv (3)
>  function.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR imaxdiv (3)
> @@ -379,7 +389,8 @@ is defined and
>  .I long long
>  is less than 128 bits wide.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also the
>  .I uintmax_t
> @@ -453,7 +464,8 @@ for scanning
>  .I int8_t
>  values.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also the
>  .IR __int128 ,
> @@ -505,7 +517,8 @@ Contains members related to the formatting of numeric 
> values.
>  In the "C" locale, its members have the values
>  shown in the comments above.
>  .PP
> -Conforming to: C11 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C11 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR setlocale (3),
> @@ -532,7 +545,8 @@ It is the type of the value returned by the
>  .BR ldiv (3)
>  function.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR ldiv (3)
> @@ -556,7 +570,8 @@ It is the type of the value returned by the
>  .BR lldiv (3)
>  function.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR lldiv (3)
> @@ -591,7 +606,8 @@ where the width of
>  is no greater than the width of the type
>  .IR long .
>  .PP
> -Conforming to: POSIX.1-2001 and later.
> +Conforming to:
> +POSIX.1-2001 and later.
>  .PP
>  See also:
>  .BR fork (2),
> @@ -638,7 +654,8 @@ for printing
>  .I ptrdiff_t
>  values.
>  .PP
> -Conforming to: C99 and later; POSIX.1-2001 and later.
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
>  .PP
>  See also the
>  .I size_t
> @@ -666,7 +683,8 @@ typedef struct {
>  .PP
>  This is a struc

Re: [PATCH 03/16] system_data_types.7: srcfix

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)

Yeah, this layout is my preferred form as well.

Applied.

Thanks,

Michael


> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index a653a7b11..a099c0250 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -406,7 +406,10 @@ Include:
>  Alternatively,
>  .IR  .
>  .PP
> -.IR int8_t ", " int16_t ", " int32_t ", " int64_t
> +.IR int8_t ,
> +.IR int16_t ,
> +.IR int32_t ,
> +.I int64_t
>  .PP
>  A signed integer type
>  of a fixed width of exactly N bits,
> @@ -418,7 +421,8 @@ capable of storing values in the range
>  substituting N by the appropriate number.
>  .PP
>  According to POSIX,
> -.IR int8_t ", " int16_t
> +.IR int8_t ,
> +.IR int16_t
>  and
>  .I int32_t
>  are required;
> @@ -1299,7 +1303,10 @@ Include:
>  Alternatively,
>  .IR  .
>  .PP
> -.IR uint8_t ", " uint16_t ", " uint32_t ", " uint64_t
> +.IR uint8_t ,
> +.IR uint16_t ,
> +.IR uint32_t ,
> +.I uint64_t
>  .PP
>  An unsigned integer type
>  of a fixed width of exactly N bits,
> @@ -1310,7 +1317,8 @@ capable of storing values in the range [0,
>  substituting N by the appropriate number.
>  .PP
>  According to POSIX,
> -.IR uint8_t ", " uint16_t
> +.IR uint8_t ,
> +.IR uint16_t
>  and
>  .I uint32_t
>  are required;
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 04/16] system_data_types.7: srcfix

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> We used .br to force a simple line break (with no extra blank line)
> after the tag.
> 
> Recently, we added .RS/.RS, and .RS comes just after the tag,
> and I realized by accident that .RS already forces a simple line break.
> 
> Therefore, .br is completely redundant here, and can be removed.
> 
> This way we get rid of "raw" *roff requests in this page.
> 
> Signed-off-by: Alejandro Colomar 

Great! Thanks for the clean-up.

Applied.

Cheers,

Michael

> ---
>  man7/system_data_types.7 | 34 --
>  1 file changed, 34 deletions(-)
> 
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index a099c0250..a301c2309 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -52,7 +52,6 @@ system_data_types \- overview of system data types
>  .TP
>  .I aiocb
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -88,7 +87,6 @@ See also:
>  .TP
>  .I div_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -113,7 +111,6 @@ See also:
>  .TP
>  .I double_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -156,7 +153,6 @@ type in this page.
>  .TP
>  .I fenv_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -174,7 +170,6 @@ See also:
>  .TP
>  .I fexcept_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -192,7 +187,6 @@ See also:
>  .TP
>  .I FILE
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -217,7 +211,6 @@ See also:
>  .TP
>  .I float_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -260,7 +253,6 @@ type in this page.
>  .TP
>  .I gid_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -293,7 +285,6 @@ See also:
>  .TP
>  .I id_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -318,7 +309,6 @@ See also:
>  .TP
>  .I imaxdiv_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -343,7 +333,6 @@ See also:
>  .TP
>  .I intmax_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -400,7 +389,6 @@ type in this page.
>  .TP
>  .IR int N _t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -484,7 +472,6 @@ types in this page.
>  .TP
>  .I lconv
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -534,7 +521,6 @@ See also:
>  .TP
>  .I ldiv_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -559,7 +545,6 @@ See also:
>  .TP
>  .I lldiv_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -584,7 +569,6 @@ See also:
>  .TP
>  .I pid_t
>  .RS
> -.br
>  Include
>  .IR  .
>  Alternatively,
> @@ -631,7 +615,6 @@ See also:
>  .TP
>  .I ptrdiff_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -671,7 +654,6 @@ types in this page.
>  .TP
>  .I regmatch_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -697,7 +679,6 @@ See also:
>  .TP
>  .I regoff_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -731,7 +712,6 @@ types in this page.
>  .TP
>  .I sigevent
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -780,7 +760,6 @@ structure in this page.
>  .TP
>  .I siginfo_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -817,7 +796,6 @@ See also:
>  .TP
>  .I sigset_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -847,7 +825,6 @@ See also:
>  .TP
>  .I sigval
>  .RS
> -.br
>  Include:
>  .IR  .
>  .PP
> @@ -880,7 +857,6 @@ in this page.
>  .TP
>  .I size_t
>  .RS
> -.br
>  Include:
>  .I 
>  or
> @@ -981,7 +957,6 @@ types in this page.
>  .TP
>  .I ssize_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1052,7 +1027,6 @@ types in this page.
>  .TP
>  .I suseconds_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1080,7 +1054,6 @@ structure in this page.
>  .TP
>  .I time_t
>  .RS
> -.br
>  Include:
>  .I 
>  or
> @@ -1118,7 +1091,6 @@ See also:
>  .TP
>  .I timer_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1142,7 +1114,6 @@ See also:
>  .TP
>  .I timespec
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1177,7 +1148,6 @@ See also:
>  .TP
>  .I timeval
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1210,7 +1180,6 @@ See also:
>  .TP
>  .I uid_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1241,7 +1210,6 @@ See also:
>  .TP
>  .I uintmax_t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1297,7 +1265,6 @@ type in this page.
>  .TP
>  .IR uint N _t
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> @@ -1384,7 +1351,6 @@ types in this page.
>  .TP
>  .I va_list
>  .RS
> -.br
>  Include:
>  .IR  .
>  Alternatively,
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 14/16] intptr_t.3: New link to system_data_types(7)

[Michael Kerrisk (man-pages) via Gcc]

Applied.

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/intptr_t.3 | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 man3/intptr_t.3
> 
> diff --git a/man3/intptr_t.3 b/man3/intptr_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/intptr_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 15/16] system_data_types.7: Add 'uintptr_t'

[Michael Kerrisk (man-pages) via Gcc]

Hi ALex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 68 
>  1 file changed, 68 insertions(+)


Thanks. Patch applied.

Cheers,

Michael


> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index 2632436ed..8884d3e18 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -1714,6 +1714,74 @@ and
>  .I unsigned __int128
>  types in this page.
>  .RE
> +.\"- uintptr_t /
> +.TP
> +.I uintptr_t
> +.RS
> +Include:
> +.IR  .
> +Alternatively,
> +.IR  .
> +.PP
> +An unsigned integer type
> +such that any valid
> +.RI ( "void *" )
> +value can be converted to this type and back.
> +According to the C language standard, it shall be
> +capable of storing values in the range [0,
> +.BR UINTPTR_MAX ].
> +.PP
> +The length modifier for
> +.I uintptr_t
> +for the
> +.BR printf (3)
> +family of functions
> +is expanded by the macros
> +.BR PRIuPTR,
> +.BR PRIoPTR,
> +.B PRIxPTR
> +and
> +.B PRIXPTR
> +(defined in
> +.IR  );
> +resulting commonly in
> +.B %"PRIuPTR"
> +or
> +.B %"PRIxPTR"
> +for printing
> +.I uintptr_t
> +values.
> +The length modifier for
> +.I uintptr_t
> +for the
> +.BR scanf (3)
> +family of functions
> +is expanded by the macros
> +.BR SCNuPTR,
> +.BR SCNoPTR,
> +.B SCNxPTR
> +and
> +.B SCNXPTR
> +(defined in
> +.IR  );
> +resulting commonly in
> +.B %"SCNuPTR"
> +or
> +.B %"SCNxPTR"
> +for scanning
> +.I uintptr_t
> +values.
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +See also the
> +.I intptr_t
> +and
> +.I void *
> +.\" TODO: Document void *
> +types in this page.
> +.RE
>  .\"- va_list --/
>  .TP
>  .I va_list
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 13/16] system_data_types.7: Add 'intptr_t'

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 65 
>  1 file changed, 65 insertions(+)

Thanks. Patch applied.

Cheers,

Michael

> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index f768e87ba..2632436ed 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -616,6 +616,71 @@ and
>  .I unsigned __int128
>  types in this page.
>  .RE
> +.\"- intptr_t -/
> +.TP
> +.I intptr_t
> +.RS
> +Include:
> +.IR  .
> +Alternatively,
> +.IR  .
> +.PP
> +A signed integer type
> +such that any valid
> +.RI ( "void *" )
> +value can be converted to this type and back.
> +According to the C language standard, it shall be
> +capable of storing values in the range
> +.RB [ INTPTR_MIN ,
> +.BR INTPTR_MAX ].
> +.PP
> +The length modifier for
> +.I intptr_t
> +for the
> +.BR printf (3)
> +family of functions
> +is expanded by the macros
> +.B PRIdPTR
> +and
> +.B PRIiPTR
> +(defined in
> +.IR  );
> +resulting commonly in
> +.B %"PRIdPTR"
> +or
> +.B %"PRIiPTR"
> +for printing
> +.I intptr_t
> +values.
> +The length modifier for
> +.I intptr_t
> +for the
> +.BR scanf (3)
> +family of functions
> +is expanded by the macros
> +.B SCNdPTR
> +and
> +.B SCNiPTR,
> +(defined in
> +.IR  );
> +resulting commonly in
> +.B %"SCNdPTR"
> +or
> +.B %"SCNiPTR"
> +for scanning
> +.I intptr_t
> +values.
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +See also the
> +.I uintptr_t
> +and
> +.I void *
> +.\" TODO: Document void *
> +types in this page.
> +.RE
>  .\"- lconv /
>  .TP
>  .I lconv
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 16/16] uintptr_t.3: New link to system_data_types(7)

[Michael Kerrisk (man-pages) via Gcc]

Applied.

On 10/1/20 12:16 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/uintptr_t.3 | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 man3/uintptr_t.3
> 
> diff --git a/man3/uintptr_t.3 b/man3/uintptr_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uintptr_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 00/16] Fixes; Document remaining stdint.h types

[Alejandro Colomar via Gcc]

Hi Michael,

I did it this way because then you have a clearly ordered list
of the commits, and in which order they go,
so I thought it might be easier for you (creating less conflicts).

And also, I can hold any more recent patches, such as __int128,
for when you finish applying the previous set, so I fix the
conflicts before you ever see them.

Don't you think?

I don't mind fixing for example patch 5,
and then rebasing the rest (and also the patches I didn't send yet),
and resending them as an answer to v1 00/16.

But if you still prefer smaller sets, I'll send you smaller sets.

It's just that these patches are usually very dependent of the
previous ones, and therefore prone to conflicts if you
don't apply them in the same exact order.

Your thoughts?

Thanks,

Alex

On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote:

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:

Hi Michael,

Here are a few fixes (including one removing .br),
and then the remaining stdint types.


These very long patch series are a bit overwhelming for me.
I'd have preferred a few smaller patch series. For example,
I think I would have preferred 3 series like this:

1-4
5-12
13-16

One reason is that the multiple parallel reply threads that
sometimes occur can sometimes be rather difficult to track.
(Your patches have started some quite useful conversations!)

For example, I suspect Jonathan's comments may trigger changes
for patches 5-12.

For now, I'm applying 1-4 and 13-16. It looks like some reworking is
going to be needed for the others. When you do resubmit them, please
start a new thread (rather than replying into this thread).

Thanks,

Michael


Alejandro Colomar (16):
   malloc_get_state.3: ffix
   system_data_types.7: srcfix
   system_data_types.7: srcfix
   system_data_types.7: srcfix
   system_data_types.7: Add int_fastN_t family of types
   int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,
 int_fastN_t.3: New links to system_data_types(7)
   system_data_types.7: Add uint_fastN_t family of types
   uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3,
 uint_fastN_t.3: New links to system_data_types(7)
   system_data_types.7: Add int_leastN_t family of types
   int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3,
 int_leastN_t.3: New links to system_data_types(7)
   system_data_types.7: Add uint_leastN_t family of types
   uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3,
 uint_leastN_t.3: New links to system_data_types(7)
   system_data_types.7: Add 'intptr_t'
   intptr_t.3: New link to system_data_types(7)
   system_data_types.7: Add 'uintptr_t'
   uintptr_t.3: New link to system_data_types(7)

  man3/int_fast16_t.3  |   1 +
  man3/int_fast32_t.3  |   1 +
  man3/int_fast64_t.3  |   1 +
  man3/int_fast8_t.3   |   1 +
  man3/int_fastN_t.3   |   1 +
  man3/int_least16_t.3 |   1 +
  man3/int_least32_t.3 |   1 +
  man3/int_least64_t.3 |   1 +
  man3/int_least8_t.3  |   1 +
  man3/int_leastN_t.3  |   1 +
  man3/intptr_t.3  |   1 +
  man3/malloc_get_state.3  |   2 +-
  man3/uint_fast16_t.3 |   1 +
  man3/uint_fast32_t.3 |   1 +
  man3/uint_fast64_t.3 |   1 +
  man3/uint_fast8_t.3  |   1 +
  man3/uint_fastN_t.3  |   1 +
  man3/uint_least16_t.3|   1 +
  man3/uint_least32_t.3|   1 +
  man3/uint_least64_t.3|   1 +
  man3/uint_least8_t.3 |   1 +
  man3/uint_leastN_t.3 |   1 +
  man3/uintptr_t.3 |   1 +
  man7/system_data_types.7 | 590 ++-
  24 files changed, 540 insertions(+), 74 deletions(-)
  create mode 100644 man3/int_fast16_t.3
  create mode 100644 man3/int_fast32_t.3
  create mode 100644 man3/int_fast64_t.3
  create mode 100644 man3/int_fast8_t.3
  create mode 100644 man3/int_fastN_t.3
  create mode 100644 man3/int_least16_t.3
  create mode 100644 man3/int_least32_t.3
  create mode 100644 man3/int_least64_t.3
  create mode 100644 man3/int_least8_t.3
  create mode 100644 man3/int_leastN_t.3
  create mode 100644 man3/intptr_t.3
  create mode 100644 man3/uint_fast16_t.3
  create mode 100644 man3/uint_fast32_t.3
  create mode 100644 man3/uint_fast64_t.3
  create mode 100644 man3/uint_fast8_t.3
  create mode 100644 man3/uint_fastN_t.3
  create mode 100644 man3/uint_least16_t.3
  create mode 100644 man3/uint_least32_t.3
  create mode 100644 man3/uint_least64_t.3
  create mode 100644 man3/uint_least8_t.3
  create mode 100644 man3/uint_leastN_t.3
  create mode 100644 man3/uintptr_t.3


H

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

[Jonathan Wakely via Gcc]

On Thu, 1 Oct 2020 at 12:24, Alejandro Colomar  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: [PATCH 00/16] Fixes; Document remaining stdint.h types

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

On 10/1/20 1:41 PM, Alejandro Colomar wrote:
> Hi Michael,
> 
> I did it this way because then you have a clearly ordered list
> of the commits, and in which order they go,
> so I thought it might be easier for you (creating less conflicts).

Yes, I understand the rationale. But when I get a series of
loosely related patches in a series of 20, and multiple
conversations start about independent topics, I'm finding
it quite some effort to keep track.

> And also, I can hold any more recent patches, such as __int128,
> for when you finish applying the previous set, so I fix the
> conflicts before you ever see them.
> 
> Don't you think?
> 
> I don't mind fixing for example patch 5,
> and then rebasing the rest (and also the patches I didn't send yet),
> and resending them as an answer to v1 00/16.
> 
> But if you still prefer smaller sets, I'll send you smaller sets.

I do prefer smaller sets. And yes, occasionally things may
go wrong in terms of patch conflicts, but I think that may be 
a smaller than the problem I note above.

> It's just that these patches are usually very dependent of the
> previous ones, and therefore prone to conflicts if you
> don't apply them in the same exact order.
> 
> Your thoughts?

As you can see, there's no perfect solution here. In such
situations what I try to do (where possible) is order the
patches from least contentious to most contentious.
That way, the patches that are almost certainly going to 
be applied are loaded at the front and the chance of having
to rebasing later patches in a series is lower.

Thanks,

Michael



> On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote:
>> Hi Alex,
>>
>> On 10/1/20 12:15 PM, Alejandro Colomar wrote:
>>> Hi Michael,
>>>
>>> Here are a few fixes (including one removing .br),
>>> and then the remaining stdint types.
>>
>> These very long patch series are a bit overwhelming for me.
>> I'd have preferred a few smaller patch series. For example,
>> I think I would have preferred 3 series like this:
>>
>> 1-4
>> 5-12
>> 13-16
>>
>> One reason is that the multiple parallel reply threads that
>> sometimes occur can sometimes be rather difficult to track.
>> (Your patches have started some quite useful conversations!)
>>
>> For example, I suspect Jonathan's comments may trigger changes
>> for patches 5-12.
>>
>> For now, I'm applying 1-4 and 13-16. It looks like some reworking is
>> going to be needed for the others. When you do resubmit them, please
>> start a new thread (rather than replying into this thread).
>>
>> Thanks,
>>
>> Michael
>>
>>> Alejandro Colomar (16):
>>>malloc_get_state.3: ffix
>>>system_data_types.7: srcfix
>>>system_data_types.7: srcfix
>>>system_data_types.7: srcfix
>>>system_data_types.7: Add int_fastN_t family of types
>>>int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,
>>>  int_fastN_t.3: New links to system_data_types(7)
>>>system_data_types.7: Add uint_fastN_t family of types
>>>uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3,
>>>  uint_fastN_t.3: New links to system_data_types(7)
>>>system_data_types.7: Add int_leastN_t family of types
>>>int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3,
>>>  int_leastN_t.3: New links to system_data_types(7)
>>>system_data_types.7: Add uint_leastN_t family of types
>>>uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3,
>>>  uint_leastN_t.3: New links to system_data_types(7)
>>>system_data_types.7: Add 'intptr_t'
>>>intptr_t.3: New link to system_data_types(7)
>>>system_data_types.7: Add 'uintptr_t'
>>>uintptr_t.3: New link to system_data_types(7)
>>>
>>>   man3/int_fast16_t.3  |   1 +
>>>   man3/int_fast32_t.3  |   1 +
>>>   man3/int_fast64_t.3  |   1 +
>>>   man3/int_fast8_t.3   |   1 +
>>>   man3/int_fastN_t.3   |   1 +
>>>   man3/int_least16_t.3 |   1 +
>>>   man3/int_least32_t.3 |   1 +
>>>   man3/int_least64_t.3 |   1 +
>>>   man3/int_least8_t.3  |   1 +
>>>   man3/int_leastN_t.3  |   1 +
>>>   man3/intptr_t.3  |   1 +
>>>   man3/malloc_get_state.3  |   2 +-
>>>   man3/uint_fast16_t.3 |   1 +
>>>   man3/uint_fast32_t.3 |   1 +
>>>   man3/uint_fast64_t.3 |   1 +
>>>   man3/uint_fast8_t.3  |   1 +
>>>   man3/uint_fastN_t.3  |   1 +
>>>   man3/uint_least16_t.3|   1 +
>>>   man3/uint_least32_t.3|   1 +
>>>   man3/uint_least64_t.3|   1 +
>>>   man3/uint_least8_t.3 |   1 +
>>>   man3/uint_leastN_t.3 |   1 +
>>>   man3/uintptr_t.3 |   1 +
>>>   man7/system_data_types.7 | 590 ++-
>>>   24 files changed, 540 insertions(+), 74 deletions(-)
>>>   create mode 100644 man3/int_fast16_t.3
>>>   create mode 100644 man3/int_fast32_t.3
>>>   create mode 100644 man3/int_fast64_t.3
>>>   create mode 100644 man3/int_fast8_t.3
>>>   create mode 100644 man3/int_fastN_t.3
>>>   create mode 100644 man3/int_least

Re: [PATCH 00/16] Fixes; Document remaining stdint.h types

[Alejandro Colomar via Gcc]

Okay then :)

Thanks,

Alex

On 2020-10-01 13:50, Michael Kerrisk (man-pages) wrote:

Hi Alex,

On 10/1/20 1:41 PM, Alejandro Colomar wrote:

Hi Michael,

I did it this way because then you have a clearly ordered list
of the commits, and in which order they go,
so I thought it might be easier for you (creating less conflicts).


Yes, I understand the rationale. But when I get a series of
loosely related patches in a series of 20, and multiple
conversations start about independent topics, I'm finding
it quite some effort to keep track.


And also, I can hold any more recent patches, such as __int128,
for when you finish applying the previous set, so I fix the
conflicts before you ever see them.

Don't you think?

I don't mind fixing for example patch 5,
and then rebasing the rest (and also the patches I didn't send yet),
and resending them as an answer to v1 00/16.

But if you still prefer smaller sets, I'll send you smaller sets.


I do prefer smaller sets. And yes, occasionally things may
go wrong in terms of patch conflicts, but I think that may be
a smaller than the problem I note above.


It's just that these patches are usually very dependent of the
previous ones, and therefore prone to conflicts if you
don't apply them in the same exact order.

Your thoughts?


As you can see, there's no perfect solution here. In such
situations what I try to do (where possible) is order the
patches from least contentious to most contentious.
That way, the patches that are almost certainly going to
be applied are loaded at the front and the chance of having
to rebasing later patches in a series is lower.

Thanks,

Michael




On 2020-10-01 13:32, Michael Kerrisk (man-pages) wrote:

Hi Alex,

On 10/1/20 12:15 PM, Alejandro Colomar wrote:

Hi Michael,

Here are a few fixes (including one removing .br),
and then the remaining stdint types.


These very long patch series are a bit overwhelming for me.
I'd have preferred a few smaller patch series. For example,
I think I would have preferred 3 series like this:

1-4
5-12
13-16

One reason is that the multiple parallel reply threads that
sometimes occur can sometimes be rather difficult to track.
(Your patches have started some quite useful conversations!)

For example, I suspect Jonathan's comments may trigger changes
for patches 5-12.

For now, I'm applying 1-4 and 13-16. It looks like some reworking is
going to be needed for the others. When you do resubmit them, please
start a new thread (rather than replying into this thread).

Thanks,

Michael

Re: Fwd: Re: Registers used for exception handling on Linux/m68k?

[Nathan Sidwell]

On 10/1/20 5:49 AM, John Paul Adrian Glaubitz wrote:

Hi Nathan!

On 9/29/20 7:58 PM, Nathan Sidwell wrote:

On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote:


I'm looking for an information regarding exception handling on Linux/m68k, in 
particular
I need to know what registers are used by the ABI in order to implement the 
functions
"getExceptionPointerRegister" and "getExceptionSelectorRegister" in the M680x0 
backend
in LLVM [1], [2].


I don;t know what those functions are, but from their names they seem to be 
related to figuring out the exception object and type?


I think so. I'm not a compiler expert hence my questions :-).


Do you understand the itanium ABI's unwinding mechanism --
1) follow stack to get to landing pad.
2) invoke landing pad to see if it wants to catch
3) if not, continue following stack
4) once we've found one to catch it, we need to unwind properly, which involves 
invoking cleanups. and eventually getting to the catcher

invoking the landing pad means passing (a) an integer telling it what's 
happening, and (b) a pointer to data.


This seems to be the data that I need. I just need to understand how that works.


I realized I'd got some details confused (it's been quite a while since 
I've dealt with this code).


When locating a landing pad to catch the exception the unwinder uses a 
personality routine, and passes it some data from the unwind table. 
That's a regular call in the context of the unwinder.  (It's called a 
personality routine, because it's keyed to the language trying to catch 
the exception.)  The landing pads are not called in this case.


The landing pad executes in the context of the function it's a landing 
pad for.  So the SP must be the expected one, all the (callee-save) 
registers must be as they were at the point of calling the function that 
threw, and everything below the SP is dead.  Of course the unwinder's 
frame is somewhere down the stack, and now dead.  eh_return is the thing 
that (a) adjusts the SP and (b) indirect jumps to the landing pad.  That 
is what the EH_Return macro is.  That code is in the unwinder, and is 
compiler-specific.






I looked into the GCC source code to find the corresponding parts but I could 
only find
the macros prefixed with "EH_" [4] which I didn't fully understand.


Those are the bits you want.  one of those is the selector (0?) and the other 
is the data pointer (1?).


OK. But aren't they passed through particular registers on m68k? Or is this 
something specific
to LLVM?


Sorry, I think I confused the issue by conflating the eh_return 
(compiler-specific) with the passing of eh objects to the landing pad 
(ABI-specified).


do you know what those 2 functions you mention provide on say x86?  Then 
it might be easier to map onto 68k.


nathan

--
Nathan Sidwell

Re: Fwd: Re: Registers used for exception handling on Linux/m68k?

[John Paul Adrian Glaubitz]

Hi Nathan!

Thanks for the explanations!

On 10/1/20 2:27 PM, Nathan Sidwell wrote:
> do you know what those 2 functions you mention provide on say x86?  Then it 
> might be easier to map onto 68k.

>From [1]:

Register X86TargetLowering::getExceptionPointerRegister(
const Constant *PersonalityFn) const {
  if (classifyEHPersonality(PersonalityFn) == EHPersonality::CoreCLR)
return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;

  return Subtarget.isTarget64BitLP64() ? X86::RAX : X86::EAX;
}

Register X86TargetLowering::getExceptionSelectorRegister(
const Constant *PersonalityFn) const {
  // Funclet personalities don't use selectors (the runtime does the selection).
  assert(!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn)));
  return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
}

Adrian

> [1] 
> https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Fwd: Re: Registers used for exception handling on Linux/m68k?

[Nathan Sidwell]

On 10/1/20 8:32 AM, John Paul Adrian Glaubitz wrote:

Hi Nathan!

Thanks for the explanations!

On 10/1/20 2:27 PM, Nathan Sidwell wrote:

do you know what those 2 functions you mention provide on say x86?  Then it 
might be easier to map onto 68k.


 From [1]:

Register X86TargetLowering::getExceptionPointerRegister(
 const Constant *PersonalityFn) const {
   if (classifyEHPersonality(PersonalityFn) == EHPersonality::CoreCLR)
 return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;

   return Subtarget.isTarget64BitLP64() ? X86::RAX : X86::EAX;
}

Register X86TargetLowering::getExceptionSelectorRegister(
 const Constant *PersonalityFn) const {
   // Funclet personalities don't use selectors (the runtime does the 
selection).
   assert(!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn)));
   return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
}


Aha!  it is EH_RETURN :) and it appears stack adjustment is something 
different.


for x86, gcc has:
#define EH_RETURN_DATA_REGNO(N) ((N) <= DX_REG ? (N) : INVALID_REGNUM)

thus N can either be AX_REG or DX_REG. (which is eax/rax and edx/rdx 
depending on compilation mode)


for m68k gcc has:
#define EH_RETURN_DATA_REGNO(N) \
  ((N) < 2 ? (N) : INVALID_REGNUM)

so that's registers d0 and d1

I'm guessing EHPersonality:CoreCLR is a different ABI that you're not 
concerned with.  Thus I think you want:


getExceptionPointerRegister to return d0 and 
getExceptionSelectorRegister to return d1.


give that a go, and see if you can throw/catch exceptions between code 
compiled by your llvm port and a gcc


hope that helps.



Adrian


[1] 
https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp





--
Nathan Sidwell

Re: Fwd: Re: Registers used for exception handling on Linux/m68k?

[John Paul Adrian Glaubitz]

On 10/1/20 2:46 PM, Nathan Sidwell wrote:
> Aha!  it is EH_RETURN :) and it appears stack adjustment is something 
> different.
> 
> for x86, gcc has:
> #define EH_RETURN_DATA_REGNO(N)    ((N) <= DX_REG ? (N) : INVALID_REGNUM)
> 
> thus N can either be AX_REG or DX_REG. (which is eax/rax and edx/rdx 
> depending on compilation mode)
> 
> for m68k gcc has:
> #define EH_RETURN_DATA_REGNO(N) \
>   ((N) < 2 ? (N) : INVALID_REGNUM)
> 
> so that's registers d0 and d1
> 
> I'm guessing EHPersonality:CoreCLR is a different ABI that you're not 
> concerned with.

Yeah, it also seems to be present in the X86 backend only (at least not in the 
Sparc backend).

> Thus I think you want:
> 
> getExceptionPointerRegister to return d0 and getExceptionSelectorRegister to 
> return d1.
> 
> give that a go, and see if you can throw/catch exceptions between code 
> compiled by your llvm port and a gcc

Perfect, thanks.

> hope that helps.
I'll give it a try.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Szabolcs Nagy via Gcc]

The 10/01/2020 12:14, Alejandro Colomar via Gcc wrote:
> Here is the rendered intmax_t:
> 
> intmax_t
>   Include: .  Alternatively, .
> 
>   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.

UB or !UB? Plus poor register allocation

[Stefan Kanthak]

The following source implements the __absv?i2() functions (see
)
for 32-bit, 64-bit and 128-bit integers in 3 different ways:

--- ub_or_!ub.c ---
// Copyleft 2014-2020, Stefan Kanthak

#ifdef __amd64__
__int128_t __absuti2(__int128_t argument) {
if (argument < 0)
argument = -argument;
if (argument < 0)
__builtin_trap();
return argument;
}

__int128_t __absvti2(__int128_t argument) {
const __int128_t sign = 0 - (argument < 0);
argument += sign;
argument ^= sign;
if (argument < 0)
__builtin_trap();
return argument;
}

__int128_t __abswti2(__int128_t argument) {
const __int128_t sign = argument >> 127;
argument ^= sign;
argument -= sign;
if (argument < 0)
__builtin_trap();
return argument;
}
#endif // __amd64__

long long __absudi2(long long argument) {
if (argument < 0)
argument = -argument;
if (argument < 0)
__builtin_trap();
return argument;
}

long long __absvdi2(long long argument) {
const long long sign = 0 - (argument < 0);
argument ^= sign;
argument -= sign;
if (argument < 0)
__builtin_trap();
return argument;
}

long long __abswdi2(long long argument) {
const long long sign = argument >> 63;
argument += sign;
argument ^= sign;
if (argument < 0)
__builtin_trap();
return argument;
}

int __absusi2(int argument) {
if (argument < 0)
argument = -argument;
if (argument < 0)
__builtin_trap();
return argument;
}

int __absvsi2(int argument) {
const int sign = 0 - (argument < 0);
argument ^= sign;
argument -= sign;
if (argument < 0)
__builtin_trap();
return argument;
}

int __abswsi2(int argument) {
const int sign = argument >> 31;
argument += sign;
argument ^= sign;
if (argument < 0)
__builtin_trap();
return argument;
}
--- EOF ---

Compile it with GCC 10.2, printing the assembly:

gcc -o- -O3 -S -Wall -Wextra ub_or_!ub.c

NOTE: older versions of GCC generate BAD code for the expression
  0 - (argument < 0)

(Output rearranged in 3 columns to ease comparision)

__absuti2:   __absvti2:   __abswti2:
movq%rsi, %rax   movq%rdi, %rax   movq%rsi, 
%rax
movq%rdi, %r8movq%rsi, %rdi   movq%rdi, 
%r8
movq%rsi, %rcx   movq%rsi, %rdx   movq%rsi, 
%rcx
sarq$63, %raxsarq$63, %rdisarq$63, 
%rax
movq%rax, %rsi   movslq  %edi, %rcx   movq%rax, 
%rsi
xorq%rax, %r8movq%rcx, %rsi   xorq%rax, 
%r8
xorq%rsi, %rcx   sarq$63, %rcxxorq%rsi, 
%rcx
movq%r8, %raxaddq%rsi, %rax   movq%r8, 
%rax
movq%rcx, %rdx   movq%rcx, %rdi   movq%rcx, 
%rdx
subq%rsi, %rax   adcq%rcx, %rdx   subq%rsi, 
%rax
sbbq%rsi, %rdx   xorq%rsi, %rax   sbbq%rsi, 
%rdx
ret  xorq%rdi, %rdx   testq   %rdx, 
%rdx
 jns .L2  jns .L5
 ud2  ud2
 .L2: .L5:
 ret  ret


__absudi2:   __absvdi2:   __abswdi2:
movq%rdi, %rax   movq%rdi, %rax   movq%rdi, 
%rdx
cqto cqto sarq$63, 
%rdx
xorq%rdx, %rax   movslq  %edx, %rdx   leaq
(%rdi,%rdx), %rax
subq%rdx, %rax   xorq%rdx, %rax   xorq%rdx, 
%rax
ret  subq%rdx, %rax   jns .L10
 jns .L8  ud2
 ud2  .L10:
 .L8: ret
 ret


__absusi2:   __absvsi2:   __abswsi2:
movl%edi, %eax   movl%edi, %eax   movl%edi, 
%edx
cltd movl%edi, %edx   sarl$31, 
%edx
xorl%edx, %eax   shrl$31, %eaxleal
(%rdi,%rdx), %eax
subl%edx, %eax   movl%eax, %edi   xorl%edx, 
%eax
ret  negl%edi jns .L15
 xorl%edx, %edi   ud2
 addl%edi, %eax   .L15:

Re: Git rejecting branch merge

[Jan Hubicka]

> > So, IIUC, you're trying to replace the old
> > refs/users/hubicka/heads/honza-gcc-benchmark-branch
> > with whatever is on master at this moment, is that correct
> > (that would wipe whatever changes you've made in your old
> > branch)?
> > 
> > For instance, currently master is pointing to commit
> > adcf8a11c772e7a0c64d4ae3eb19a520566f32b9.
> 
> Yes, i want to replace it with current master.

Hello,
I wonder I can get the branch moved, so I can do the benchmarking :)
Any suggestions how to do that?

Thanks,
Honza
> 
> Thanks,
> Honza
> > 
> > -- 
> > Joel

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

[Alejandro Colomar via Gcc]

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: .  Alternatively, .

   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 via Gcc]

On Thu, 1 Oct 2020 at 14:22, Alejandro Colomar  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: .  Alternatively, .
> >>
> >>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.

GCC's Git update_hook doesn't support deleting branches

[Jonathan Wakely via Gcc]

You get a nasty error like:

$ git push origin -d refs/users/redi/heads/calendar
remote: *** Update rejected by this repository's hooks.update-hook script
remote: *** (/git/gcc.git/hooks-bin/update_hook):
remote: *** fatal: bad object 
remote: *** Traceback (most recent call last):
remote: ***   File "/git/gcc.git/hooks-bin/update_hook", line 39, in 
remote: *** main()
remote: ***   File "/git/gcc.git/hooks-bin/update_hook", line 27, in main
remote: *** check=True, universal_newlines=True).stdout.split('\n')
remote: ***   File "/usr/lib64/python3.6/subprocess.py", line 438, in run
remote: *** output=stdout, stderr=stderr)
remote: *** subprocess.CalledProcessError: Command '['git',
'rev-list', '',
'^4415a3e0965ae6e2a4bedd3584b2504ebb2d96f3']' returned non-zero exit
status 128.
remote: error: hook declined to update refs/users/redi/heads/calendar
To git+ssh://gcc.gnu.org/git/gcc.git
! [remote rejected] refs/users/redi/heads/calendar (hook declined)
error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'


The problem is that the script doesn't check whether the new_object is
0.

I think we want something like this:

--- update_hook 2020-09-02 23:30:25.074884982 +
+++ /tmp/update_hook2020-10-01 13:57:14.681656258 +
@@ -12,6 +12,12 @@
ref_name = sys.argv[1]
old_object = sys.argv[2]
new_object = sys.argv[3]
+if re.fullmatch('0+', new_object) is not None:
+if (not ref_name.startswith('refs/users/')
+and not ref_name.startswith('refs/vendors/')):
+error('Only personal and vendor branches can be deleted.')
+sys.exit(1)
+sys.exit(0)
# Do not allow updates introducing ancestry based on the old
# git-svn repository, to ensure people rebase onto the new history
# rather than merging branches based on git-svn history into those

Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

[Alejandro Colomar via Gcc]

On 2020-10-01 13:27, Jonathan Wakely wrote:

How would you word that?


I gave a suggestion above.


Oops, I missed that.

Thanks,

Alex

[PATCH v2 0/4] Document [u]int_fastN_t

[Alejandro Colomar via Gcc]

This patches are the v2 of the patches 5 to 8 of a previous patchset:
https://lore.kernel.org/linux-man/886f5647-2911-951a-b62a-4f9b1ed88...@gmail.com/T/#t

Alejandro Colomar (4):
  system_data_types.7: Add int_fastN_t family of types
  int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3,
int_fastN_t.3: New links to system_data_types(7)
  system_data_types.7: Add uint_fastN_t family of types
  uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3,
uint_fastN_t.3: New links to system_data_types(7)

 man3/int_fast16_t.3  |   1 +
 man3/int_fast32_t.3  |   1 +
 man3/int_fast64_t.3  |   1 +
 man3/int_fast8_t.3   |   1 +
 man3/int_fastN_t.3   |   1 +
 man3/uint_fast16_t.3 |   1 +
 man3/uint_fast32_t.3 |   1 +
 man3/uint_fast64_t.3 |   1 +
 man3/uint_fast8_t.3  |   1 +
 man3/uint_fastN_t.3  |   1 +
 man7/system_data_types.7 | 157 +++
 11 files changed, 167 insertions(+)
 create mode 100644 man3/int_fast16_t.3
 create mode 100644 man3/int_fast32_t.3
 create mode 100644 man3/int_fast64_t.3
 create mode 100644 man3/int_fast8_t.3
 create mode 100644 man3/int_fastN_t.3
 create mode 100644 man3/uint_fast16_t.3
 create mode 100644 man3/uint_fast32_t.3
 create mode 100644 man3/uint_fast64_t.3
 create mode 100644 man3/uint_fast8_t.3
 create mode 100644 man3/uint_fastN_t.3

-- 
2.28.0

[PATCH v2 1/4] system_data_types.7: Add int_fastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 77 
 1 file changed, 77 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 4645ed5f4..c5d0b700d 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -329,6 +329,83 @@ C99 and later; POSIX.1-2001 and later.
 See also:
 .BR imaxdiv (3)
 .RE
+.\"- int_fastN_t --/
+.TP
+.IR int_fast N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR int_fast8_t ,
+.IR int_fast16_t ,
+.IR int_fast32_t ,
+.I int_fast64_t
+.PP
+Usually the fastest (see Notes) signed integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range
+.RB [ INT_FAST N _MIN ,
+.BR INT_FAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR int_fast N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIdFAST N
+and
+.BR PRIiFAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIdFAST64"
+or
+.B %"PRIiFAST64"
+for printing
+.I int_fast64_t
+values.
+The length modifiers for the
+.IR int_fast N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNdFAST N
+and
+.BR SCNiFAST N,
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNdFAST8"
+or
+.B %"SCNiFAST8"
+for scanning
+.I int_fast8_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+Notes:
+Where there is no single type that is fastest for all purposes,
+the implementation may choose any type
+with the required signedness and at least the minimum width.
+.PP
+See also the
+.IR int_least N _t ,
+.IR int N _t ,
+.IR uint_fast N _t ,
+.IR uint_least N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- intmax_t -/
 .TP
 .I intmax_t
-- 
2.28.0

[PATCH v2 3/4] system_data_types.7: Add uint_fastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 80 
 1 file changed, 80 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index c5d0b700d..c130b7256 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -1348,6 +1348,86 @@ See also:
 .BR getpwnam (2),
 .BR credentials (7)
 .RE
+.\"- uint_fastN_t -/
+.TP
+.IR uint_fast N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR uint_fast8_t ,
+.IR uint_fast16_t ,
+.IR uint_fast32_t ,
+.I uint_fast64_t
+.PP
+Usually the fastest (see Notes) unsigned integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range [0,
+.BR UINT_FAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR uint_fast N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIuFAST N,
+.BR PRIoFAST N,
+.BR PRIxFAST N
+and
+.BR PRIXFAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIuFAST32"
+or
+.B %"PRIxFAST32"
+for printing
+.I uint_fast32_t
+values.
+The length modifiers for the
+.IR uint_fast N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNuFAST N,
+.BR SCNoFAST N,
+.BR SCNxFAST N
+and
+.BR SCNXFAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNuFAST16"
+or
+.B %"SCNxFAST16"
+for scanning
+.I uint_fast16_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+Notes:
+Where there is no single type that is fastest for all purposes,
+the implementation may choose any type
+with the required signedness and at least the minimum width.
+.PP
+See also the
+.IR int_fast N _t ,
+.IR int_least N _t ,
+.IR int N _t ,
+.IR uint_least N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- uintmax_t /
 .TP
 .I uintmax_t
-- 
2.28.0

[PATCH v2 2/4] int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3, int_fastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/int_fast16_t.3 | 1 +
 man3/int_fast32_t.3 | 1 +
 man3/int_fast64_t.3 | 1 +
 man3/int_fast8_t.3  | 1 +
 man3/int_fastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/int_fast16_t.3
 create mode 100644 man3/int_fast32_t.3
 create mode 100644 man3/int_fast64_t.3
 create mode 100644 man3/int_fast8_t.3
 create mode 100644 man3/int_fastN_t.3

diff --git a/man3/int_fast16_t.3 b/man3/int_fast16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fast32_t.3 b/man3/int_fast32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fast64_t.3 b/man3/int_fast64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fast8_t.3 b/man3/int_fast8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fast8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_fastN_t.3 b/man3/int_fastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_fastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH v2 4/4] uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3, uint_fastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/uint_fast16_t.3 | 1 +
 man3/uint_fast32_t.3 | 1 +
 man3/uint_fast64_t.3 | 1 +
 man3/uint_fast8_t.3  | 1 +
 man3/uint_fastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/uint_fast16_t.3
 create mode 100644 man3/uint_fast32_t.3
 create mode 100644 man3/uint_fast64_t.3
 create mode 100644 man3/uint_fast8_t.3
 create mode 100644 man3/uint_fastN_t.3

diff --git a/man3/uint_fast16_t.3 b/man3/uint_fast16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fast32_t.3 b/man3/uint_fast32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fast64_t.3 b/man3/uint_fast64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fast8_t.3 b/man3/uint_fast8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fast8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_fastN_t.3 b/man3/uint_fastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_fastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH v2 2/4] int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3, int_leastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/int_least16_t.3 | 1 +
 man3/int_least32_t.3 | 1 +
 man3/int_least64_t.3 | 1 +
 man3/int_least8_t.3  | 1 +
 man3/int_leastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/int_least16_t.3
 create mode 100644 man3/int_least32_t.3
 create mode 100644 man3/int_least64_t.3
 create mode 100644 man3/int_least8_t.3
 create mode 100644 man3/int_leastN_t.3

diff --git a/man3/int_least16_t.3 b/man3/int_least16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_least32_t.3 b/man3/int_least32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_least64_t.3 b/man3/int_least64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_least8_t.3 b/man3/int_least8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_least8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/int_leastN_t.3 b/man3/int_leastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/int_leastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH v2 0/4] Document [u]int_leastN_t

[Alejandro Colomar via Gcc]

This patches are the v2 of the patches 9 to 12 of a previous patchset:
https://lore.kernel.org/linux-man/886f5647-2911-951a-b62a-4f9b1ed88...@gmail.com/T/#t

Alejandro Colomar (4):
  system_data_types.7: Add int_leastN_t family of types
  int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3,
int_leastN_t.3: New links to system_data_types(7)
  system_data_types.7: Add uint_leastN_t family of types
  uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3,
uint_leastN_t.3: New links to system_data_types(7)

 man3/int_least16_t.3 |   1 +
 man3/int_least32_t.3 |   1 +
 man3/int_least64_t.3 |   1 +
 man3/int_least8_t.3  |   1 +
 man3/int_leastN_t.3  |   1 +
 man3/uint_least16_t.3|   1 +
 man3/uint_least32_t.3|   1 +
 man3/uint_least64_t.3|   1 +
 man3/uint_least8_t.3 |   1 +
 man3/uint_leastN_t.3 |   1 +
 man7/system_data_types.7 | 147 +++
 11 files changed, 157 insertions(+)
 create mode 100644 man3/int_least16_t.3
 create mode 100644 man3/int_least32_t.3
 create mode 100644 man3/int_least64_t.3
 create mode 100644 man3/int_least8_t.3
 create mode 100644 man3/int_leastN_t.3
 create mode 100644 man3/uint_least16_t.3
 create mode 100644 man3/uint_least32_t.3
 create mode 100644 man3/uint_least64_t.3
 create mode 100644 man3/uint_least8_t.3
 create mode 100644 man3/uint_leastN_t.3

-- 
2.28.0

[PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 72 
 1 file changed, 72 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index c130b7256..3336de463 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -406,6 +406,78 @@ and
 .IR uint N _t
 types in this page.
 .RE
+.\"- int_leastN_t -/
+.TP
+.IR int_least N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR int_least8_t ,
+.IR int_least16_t ,
+.IR int_least32_t ,
+.I int_least64_t
+.PP
+The narrowest signed integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range
+.RB [ INT_LEAST N _MIN ,
+.BR INT_LEAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR int_least N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIdLEAST N
+and
+.BR PRIiLEAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIdLEAST64"
+or
+.B %"PRIiLEAST64"
+for printing
+.I int_least64_t
+values.
+The length modifiers for the
+.IR int_least N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNdLEAST N
+and
+.BR SCNiLEAST N,
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNdLEAST8"
+or
+.B %"SCNiLEAST8"
+for scanning
+.I int_least8_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.IR int_fast N _t ,
+.IR int N _t ,
+.IR uint_fast N _t ,
+.IR uint_least N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- intmax_t -/
 .TP
 .I intmax_t
-- 
2.28.0

[PATCH v2 3/4] system_data_types.7: Add uint_leastN_t family of types

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 75 
 1 file changed, 75 insertions(+)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 3336de463..e42cf2557 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -1500,6 +1500,81 @@ and
 .IR uint N _t
 types in this page.
 .RE
+.\"- uint_leastN_t /
+.TP
+.IR uint_least N _t
+.RS
+Include:
+.IR  .
+Alternatively,
+.IR  .
+.PP
+.IR uint_least8_t ,
+.IR uint_least16_t ,
+.IR uint_least32_t ,
+.I uint_least64_t
+.PP
+The narrowest unsigned integer type
+of a width of at least N bits,
+N being the value specified in its type name.
+According to the C language standard, they shall be
+capable of storing values in the range [0,
+.BR UINT_LEAST N _MAX ],
+substituting N by the appropriate number.
+.PP
+The length modifiers for the
+.IR uint_least N _t
+types for the
+.BR printf (3)
+family of functions
+are expanded by macros of the forms
+.BR PRIuLEST N,
+.BR PRIoLEAST N,
+.BR PRIxLEAST N
+and
+.BR PRIXLEAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"PRIuLEAST32"
+or
+.B %"PRIxLEAST32"
+for printing
+.I uint_least32_t
+values.
+The length modifiers for the
+.IR uint_least N _t
+types for the
+.BR scanf (3)
+family of functions
+are expanded by macros of the forms
+.BR SCNuLEAST N,
+.BR SCNoLEAST N,
+.BR SCNxLEAST N
+and
+.BR SCNXLEAST N
+(defined in
+.IR  );
+resulting for example in
+.B %"SCNuLEAST16"
+or
+.B %"SCNxLEAST16"
+for scanning
+.I uint_least16_t
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.IR int_fast N _t ,
+.IR int_least N _t ,
+.IR int N _t ,
+.IR uint_fast N _t
+and
+.IR uint N _t
+types in this page.
+.RE
 .\"- uintmax_t /
 .TP
 .I uintmax_t
-- 
2.28.0

[PATCH v2 4/4] uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3, uint_leastN_t.3: New links to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/uint_least16_t.3 | 1 +
 man3/uint_least32_t.3 | 1 +
 man3/uint_least64_t.3 | 1 +
 man3/uint_least8_t.3  | 1 +
 man3/uint_leastN_t.3  | 1 +
 5 files changed, 5 insertions(+)
 create mode 100644 man3/uint_least16_t.3
 create mode 100644 man3/uint_least32_t.3
 create mode 100644 man3/uint_least64_t.3
 create mode 100644 man3/uint_least8_t.3
 create mode 100644 man3/uint_leastN_t.3

diff --git a/man3/uint_least16_t.3 b/man3/uint_least16_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least16_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_least32_t.3 b/man3/uint_least32_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least32_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_least64_t.3 b/man3/uint_least64_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least64_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_least8_t.3 b/man3/uint_least8_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_least8_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
diff --git a/man3/uint_leastN_t.3 b/man3/uint_leastN_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/uint_leastN_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH 0/2] Document void *

[Alejandro Colomar via Gcc]

Hello Michael,

This type is very special,
so I will probably have missed some details about it.

Also, do you like the link name?

For anyone reading this, please comment :)

Cheers,

Alex

Alejandro Colomar (2):
  system_data_types.7: Add 'void *'
  void-*.3: New link to system_data_types(7)

 man3/void-*.3|  1 +
 man7/system_data_types.7 | 42 ++--
 2 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 man3/void-*.3

-- 
2.28.0

[PATCH 1/2] system_data_types.7: Add 'void *'

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 42 ++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e42cf2557..f10f12754 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -679,7 +679,6 @@ See also the
 .I uintptr_t
 and
 .I void *
-.\" TODO: Document void *
 types in this page.
 .RE
 .\"- lconv /
@@ -1781,7 +1780,6 @@ See also the
 .I intptr_t
 and
 .I void *
-.\" TODO: Document void *
 types in this page.
 .RE
 .\"- va_list --/
@@ -1815,6 +1813,46 @@ See also:
 .BR va_copy (3),
 .BR va_end (3)
 .RE
+.\"- void * ---/
+.TP
+.I void *
+.RS
+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a pointer to
+.I void
+and back.
+.PP
+Conversions from and to any other pointer type are done implicitly,
+not requiring casts at all.
+.PP
+The conversion specifier for
+.I void *
+for the
+.BR printf (3)
+and the
+.BR scanf (3)
+families of functions is
+.BR p ;
+resulting commonly in
+.B %p
+for printing
+.I void *
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.I intptr_t
+and
+.I uintptr_t
+types in this page.
+.RE
 .\"/
 .SH NOTES
 The structures described in this manual page shall contain,
-- 
2.28.0

[PATCH 2/2] void-*.3: New link to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/void-*.3 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 man3/void-*.3

diff --git a/man3/void-*.3 b/man3/void-*.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void-*.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

Re: [PATCH 05/16] system_data_types.7: Add int_fastN_t family of types

[Alejandro Colomar via Gcc]

On 2020-10-01 13:07, Jonathan Wakely wrote:



I don't see anything in this man page saying that the  types
are all typedefs, rather than new types that are distinct from the
standard integer types. That seems like useful information.



Hello Jonathan,

I almost missed this.

We (Michael and I) chose not to give any information
about typedefs in this page.
So the reader should not assume that any type at all,
unless explicitly specified, is a typedef.
Any type could be defined however the implementation chooses to do,
and this page will only give the requirements for the implementation.

However, if you still think we should be clearer in this point,
we might create a NOTE about this in the end of the page.

Your thoughts?

Thanks,

Alex

Re: [PATCH v2 1/4] system_data_types.7: Add int_fastN_t family of types

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.


On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 77 
>  1 file changed, 77 insertions(+)
> 
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index 4645ed5f4..c5d0b700d 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -329,6 +329,83 @@ C99 and later; POSIX.1-2001 and later.
>  See also:
>  .BR imaxdiv (3)
>  .RE
> +.\"- int_fastN_t --/
> +.TP
> +.IR int_fast N _t
> +.RS
> +Include:
> +.IR  .
> +Alternatively,
> +.IR  .
> +.PP
> +.IR int_fast8_t ,
> +.IR int_fast16_t ,
> +.IR int_fast32_t ,
> +.I int_fast64_t
> +.PP
> +Usually the fastest (see Notes) signed integer type
> +of a width of at least N bits,
> +N being the value specified in its type name.
> +According to the C language standard, they shall be
> +capable of storing values in the range
> +.RB [ INT_FAST N _MIN ,
> +.BR INT_FAST N _MAX ],
> +substituting N by the appropriate number.
> +.PP
> +The length modifiers for the
> +.IR int_fast N _t
> +types for the
> +.BR printf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR PRIdFAST N
> +and
> +.BR PRIiFAST N
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"PRIdFAST64"
> +or
> +.B %"PRIiFAST64"
> +for printing
> +.I int_fast64_t
> +values.
> +The length modifiers for the
> +.IR int_fast N _t
> +types for the
> +.BR scanf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR SCNdFAST N
> +and
> +.BR SCNiFAST N,
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"SCNdFAST8"
> +or
> +.B %"SCNiFAST8"
> +for scanning
> +.I int_fast8_t
> +values.
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +Notes:
> +Where there is no single type that is fastest for all purposes,
> +the implementation may choose any type
> +with the required signedness and at least the minimum width.
> +.PP
> +See also the
> +.IR int_least N _t ,
> +.IR int N _t ,
> +.IR uint_fast N _t ,
> +.IR uint_least N _t
> +and
> +.IR uint N _t
> +types in this page.
> +.RE
>  .\"- intmax_t -/
>  .TP
>  .I intmax_t
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 3/4] system_data_types.7: Add uint_fastN_t family of types

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.

On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 80 
>  1 file changed, 80 insertions(+)
> 
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index c5d0b700d..c130b7256 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -1348,6 +1348,86 @@ See also:
>  .BR getpwnam (2),
>  .BR credentials (7)
>  .RE
> +.\"- uint_fastN_t -/
> +.TP
> +.IR uint_fast N _t
> +.RS
> +Include:
> +.IR  .
> +Alternatively,
> +.IR  .
> +.PP
> +.IR uint_fast8_t ,
> +.IR uint_fast16_t ,
> +.IR uint_fast32_t ,
> +.I uint_fast64_t
> +.PP
> +Usually the fastest (see Notes) unsigned integer type
> +of a width of at least N bits,
> +N being the value specified in its type name.
> +According to the C language standard, they shall be
> +capable of storing values in the range [0,
> +.BR UINT_FAST N _MAX ],
> +substituting N by the appropriate number.
> +.PP
> +The length modifiers for the
> +.IR uint_fast N _t
> +types for the
> +.BR printf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR PRIuFAST N,
> +.BR PRIoFAST N,
> +.BR PRIxFAST N
> +and
> +.BR PRIXFAST N
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"PRIuFAST32"
> +or
> +.B %"PRIxFAST32"
> +for printing
> +.I uint_fast32_t
> +values.
> +The length modifiers for the
> +.IR uint_fast N _t
> +types for the
> +.BR scanf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR SCNuFAST N,
> +.BR SCNoFAST N,
> +.BR SCNxFAST N
> +and
> +.BR SCNXFAST N
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"SCNuFAST16"
> +or
> +.B %"SCNxFAST16"
> +for scanning
> +.I uint_fast16_t
> +values.
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +Notes:
> +Where there is no single type that is fastest for all purposes,
> +the implementation may choose any type
> +with the required signedness and at least the minimum width.
> +.PP
> +See also the
> +.IR int_fast N _t ,
> +.IR int_least N _t ,
> +.IR int N _t ,
> +.IR uint_least N _t
> +and
> +.IR uint N _t
> +types in this page.
> +.RE
>  .\"- uintmax_t /
>  .TP
>  .I uintmax_t
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 4/4] uint_fast8_t.3, uint_fast16_t.3, uint_fast32_t.3, uint_fast64_t.3, uint_fastN_t.3: New links to system_data_types(7)

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.

On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/uint_fast16_t.3 | 1 +
>  man3/uint_fast32_t.3 | 1 +
>  man3/uint_fast64_t.3 | 1 +
>  man3/uint_fast8_t.3  | 1 +
>  man3/uint_fastN_t.3  | 1 +
>  5 files changed, 5 insertions(+)
>  create mode 100644 man3/uint_fast16_t.3
>  create mode 100644 man3/uint_fast32_t.3
>  create mode 100644 man3/uint_fast64_t.3
>  create mode 100644 man3/uint_fast8_t.3
>  create mode 100644 man3/uint_fastN_t.3
> 
> diff --git a/man3/uint_fast16_t.3 b/man3/uint_fast16_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_fast16_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_fast32_t.3 b/man3/uint_fast32_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_fast32_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_fast64_t.3 b/man3/uint_fast64_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_fast64_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_fast8_t.3 b/man3/uint_fast8_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_fast8_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_fastN_t.3 b/man3/uint_fastN_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_fastN_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 2/4] int_fast8_t.3, int_fast16_t.3, int_fast32_t.3, int_fast64_t.3, int_fastN_t.3: New links to system_data_types(7)

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.

On 10/1/20 4:32 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/int_fast16_t.3 | 1 +
>  man3/int_fast32_t.3 | 1 +
>  man3/int_fast64_t.3 | 1 +
>  man3/int_fast8_t.3  | 1 +
>  man3/int_fastN_t.3  | 1 +
>  5 files changed, 5 insertions(+)
>  create mode 100644 man3/int_fast16_t.3
>  create mode 100644 man3/int_fast32_t.3
>  create mode 100644 man3/int_fast64_t.3
>  create mode 100644 man3/int_fast8_t.3
>  create mode 100644 man3/int_fastN_t.3
> 
> diff --git a/man3/int_fast16_t.3 b/man3/int_fast16_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_fast16_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_fast32_t.3 b/man3/int_fast32_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_fast32_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_fast64_t.3 b/man3/int_fast64_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_fast64_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_fast8_t.3 b/man3/int_fast8_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_fast8_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_fastN_t.3 b/man3/int_fastN_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_fastN_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 4/4] uint_least8_t.3, uint_least16_t.3, uint_least32_t.3, uint_least64_t.3, uint_leastN_t.3: New links to system_data_types(7)

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.

On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/uint_least16_t.3 | 1 +
>  man3/uint_least32_t.3 | 1 +
>  man3/uint_least64_t.3 | 1 +
>  man3/uint_least8_t.3  | 1 +
>  man3/uint_leastN_t.3  | 1 +
>  5 files changed, 5 insertions(+)
>  create mode 100644 man3/uint_least16_t.3
>  create mode 100644 man3/uint_least32_t.3
>  create mode 100644 man3/uint_least64_t.3
>  create mode 100644 man3/uint_least8_t.3
>  create mode 100644 man3/uint_leastN_t.3
> 
> diff --git a/man3/uint_least16_t.3 b/man3/uint_least16_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_least16_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_least32_t.3 b/man3/uint_least32_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_least32_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_least64_t.3 b/man3/uint_least64_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_least64_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_least8_t.3 b/man3/uint_least8_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_least8_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/uint_leastN_t.3 b/man3/uint_leastN_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/uint_leastN_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 2/4] int_least8_t.3, int_least16_t.3, int_least32_t.3, int_least64_t.3, int_leastN_t.3: New links to system_data_types(7)

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.

On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man3/int_least16_t.3 | 1 +
>  man3/int_least32_t.3 | 1 +
>  man3/int_least64_t.3 | 1 +
>  man3/int_least8_t.3  | 1 +
>  man3/int_leastN_t.3  | 1 +
>  5 files changed, 5 insertions(+)
>  create mode 100644 man3/int_least16_t.3
>  create mode 100644 man3/int_least32_t.3
>  create mode 100644 man3/int_least64_t.3
>  create mode 100644 man3/int_least8_t.3
>  create mode 100644 man3/int_leastN_t.3
> 
> diff --git a/man3/int_least16_t.3 b/man3/int_least16_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_least16_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_least32_t.3 b/man3/int_least32_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_least32_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_least64_t.3 b/man3/int_least64_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_least64_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_least8_t.3 b/man3/int_least8_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_least8_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> diff --git a/man3/int_leastN_t.3 b/man3/int_leastN_t.3
> new file mode 100644
> index 0..db50c0f09
> --- /dev/null
> +++ b/man3/int_leastN_t.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 3/4] system_data_types.7: Add uint_leastN_t family of types

[Michael Kerrisk (man-pages) via Gcc]

Thanks, Alex. Applied.

On 10/1/20 4:35 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar 
> ---
>  man7/system_data_types.7 | 75 
>  1 file changed, 75 insertions(+)
> 
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index 3336de463..e42cf2557 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -1500,6 +1500,81 @@ and
>  .IR uint N _t
>  types in this page.
>  .RE
> +.\"- uint_leastN_t /
> +.TP
> +.IR uint_least N _t
> +.RS
> +Include:
> +.IR  .
> +Alternatively,
> +.IR  .
> +.PP
> +.IR uint_least8_t ,
> +.IR uint_least16_t ,
> +.IR uint_least32_t ,
> +.I uint_least64_t
> +.PP
> +The narrowest unsigned integer type
> +of a width of at least N bits,
> +N being the value specified in its type name.
> +According to the C language standard, they shall be
> +capable of storing values in the range [0,
> +.BR UINT_LEAST N _MAX ],
> +substituting N by the appropriate number.
> +.PP
> +The length modifiers for the
> +.IR uint_least N _t
> +types for the
> +.BR printf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR PRIuLEST N,
> +.BR PRIoLEAST N,
> +.BR PRIxLEAST N
> +and
> +.BR PRIXLEAST N
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"PRIuLEAST32"
> +or
> +.B %"PRIxLEAST32"
> +for printing
> +.I uint_least32_t
> +values.
> +The length modifiers for the
> +.IR uint_least N _t
> +types for the
> +.BR scanf (3)
> +family of functions
> +are expanded by macros of the forms
> +.BR SCNuLEAST N,
> +.BR SCNoLEAST N,
> +.BR SCNxLEAST N
> +and
> +.BR SCNXLEAST N
> +(defined in
> +.IR  );
> +resulting for example in
> +.B %"SCNuLEAST16"
> +or
> +.B %"SCNxLEAST16"
> +for scanning
> +.I uint_least16_t
> +values.
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +See also the
> +.IR int_fast N _t ,
> +.IR int_least N _t ,
> +.IR int N _t ,
> +.IR uint_fast N _t
> +and
> +.IR uint N _t
> +types in this page.
> +.RE
>  .\"- uintmax_t /
>  .TP
>  .I uintmax_t
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 0/2] Document void *

[Michael Kerrisk (man-pages) via Gcc]

Hello Alex,

On 10/1/20 5:06 PM, Alejandro Colomar wrote:
> Hello Michael,
> 
> This type is very special,
> so I will probably have missed some details about it.

I do wonder if we actually need this in page at all, and given:

> Also, do you like the link name?

I really don't like it... I don't want to create files
whose names are globbing characters; that's a road to pain.

So, even if we did document this type in the page,
I don't think we can have a good link name. (I suppose we
could add it to the pagewithout having a link.)

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH 0/2] Document void *

[Alejandro Colomar via Gcc]

Hi Michael,

On 2020-10-01 17:34, Michael Kerrisk (man-pages) wrote:

Hello Alex,

On 10/1/20 5:06 PM, Alejandro Colomar wrote:

Hello Michael,

This type is very special,
so I will probably have missed some details about it.


I do wonder if we actually need this in page at all, and given:



I think it should be.
I would also document 'void', even if it's a bit weird...
They are very useful, so why not document them?




Also, do you like the link name?


I really don't like it... I don't want to create files
whose names are globbing characters; that's a road to pain.



Yeah, me neither... :)



So, even if we did document this type in the page,
I don't think we can have a good link name. (I suppose we
could add it to the pagewithout having a link.)



But maybe we can have a link void.3.



Thanks,

Michael




Thanks,

Alex

[PATCH v2 1/2] system_data_types.7: Add 'void *'

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man7/system_data_types.7 | 47 ++--
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index e42cf2557..e545aa1a0 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -679,7 +679,6 @@ See also the
 .I uintptr_t
 and
 .I void *
-.\" TODO: Document void *
 types in this page.
 .RE
 .\"- lconv /
@@ -1781,7 +1780,6 @@ See also the
 .I intptr_t
 and
 .I void *
-.\" TODO: Document void *
 types in this page.
 .RE
 .\"- va_list --/
@@ -1815,6 +1813,51 @@ See also:
 .BR va_copy (3),
 .BR va_end (3)
 .RE
+.\"- void * ---/
+.TP
+.I void *
+.RS
+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a pointer to
+.I void
+and back.
+.PP
+Conversions from and to any other pointer type are done implicitly,
+not requiring casts at all.
+.PP
+A value of this type can't be dereferenced,
+as it would give a value of type
+.I void
+which is not possible.
+.PP
+The conversion specifier for
+.I void *
+for the
+.BR printf (3)
+and the
+.BR scanf (3)
+families of functions is
+.BR p ;
+resulting commonly in
+.B %p
+for printing
+.I void *
+values.
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also the
+.I intptr_t
+and
+.I uintptr_t
+types in this page.
+.RE
 .\"/
 .SH NOTES
 The structures described in this manual page shall contain,
-- 
2.28.0

[PATCH v2 2/2] void.3: New link to system_data_types(7)

[Alejandro Colomar via Gcc]

Signed-off-by: Alejandro Colomar 
---
 man3/void.3 | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 man3/void.3

diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
-- 
2.28.0

[PATCH v2 0/2] Document 'void *'

[Alejandro Colomar via Gcc]

I added a paragraph about not being able to dereference a void *,
and changed the link page, which was very weird.

Alejandro Colomar (2):
  system_data_types.7: Add 'void *'
  void.3: New link to system_data_types(7)

 man3/void.3  |  1 +
 man7/system_data_types.7 | 47 ++--
 2 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 man3/void.3

-- 
2.28.0

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

[Michael Kerrisk (man-pages) via Gcc]

Hi Alex,

> +According to the C language standard,
> +a pointer to any object type may be converted to a pointer to
> +.I void
> +and back.
> +POSIX further requires that any pointer,
> +including pointers to functions,
> +may be converted to a pointer to
> +.I void
> +and back.
I know you are correct about POSIX, but which part of the 
standard did you find this information in? The only
reference that I find in POSIX is the dlsym() spec. Is it
covered also somewhere else in the standrd?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

[Alejandro Colomar via Gcc]

On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote:

Hi Alex,


+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a pointer to
+.I void
+and back.

I know you are correct about POSIX, but which part of the
standard did you find this information in? The only
reference that I find in POSIX is the dlsym() spec. Is it
covered also somewhere else in the standrd?

Thanks,

Michael



Hi Michael,

I've bean searching, and dlsym is the only one:



user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "pointer to a 
function"
functions/regfree.html:530:"undefined" means that the action 
by the application is an error, of similar severity to passing a bad 
pointer to a function.
functions/dlsym.html:138:Note that conversion from a void * 
pointer to a function pointer as in:
functions/regcomp.html:530:"undefined" means that the action 
by the application is an error, of similar severity to passing a bad 
pointer to a function.
functions/regexec.html:530:"undefined" means that the action 
by the application is an error, of similar severity to passing a bad 
pointer to a function.
functions/V2_chap02.html:3039:There are three types of action that 
can be associated with a signal: SIG_DFL, SIG_IGN, or a pointer to a 
function. Initially,
functions/regerror.html:530:"undefined" means that the action 
by the application is an error, of similar severity to passing a bad 
pointer to a function.

user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "function pointer"
basedefs/glob.h.html:165:"../functions/glob.html">glob() 
prototype definition by removing the restrict qualifier from the 
function pointer
xrat/V4_xsh_chap02.html:114:when the application requires it; for 
example, if its address is to be stored in a function pointer variable.
functions/dlsym.html:138:Note that conversion from a void * 
pointer to a function pointer as in:
user@debian:~/Desktop/src/Standards/susv4-2018$ grep -rn "pointer to 
function"
functions/dlsym.html:73:converted from type pointer to function to type 
pointer to void; otherwise, dlsym() shall return the 
address of the

user@debian:~/Desktop/src/Standards/susv4-2018$

From those, the only one that documents this is functions/dlsym.
The rest is noise.

The most explicit paragraph in dlsym is the following:

[[
Note that conversion from a void * pointer to a function pointer as in:

fptr = (int (*)(int))dlsym(handle, "my_function");

is not defined by the ISO C standard.
This standard requires this conversion to work correctly
on conforming implementations.
]]

Re: Is there a way to tell GCC not to reorder a specific instruction?

[Jim Wilson]

On Wed, Sep 30, 2020 at 11:35 PM Richard Biener
 wrote:
> On Wed, Sep 30, 2020 at 10:01 PM Jim Wilson  wrote:
> > We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
> > we are using for testing the vector support.
>
> That doesn't seem to exist (but maybe it's just not on trunk yet).

The vector extension is still in draft form, and they are still making
major compatibility breaks.  There was yet another one about 3-4 weeks
ago.  I don't want to upstream anything until we have an officially
accepted V extension, at which point they will stop allowing
compatibility breaks.  If we upstream now, we would need some protocol
for how to handle unsupported experimental patches in mainline, and I
don't think that we have one.

So for now, the vector support is on a branch in the RISC-V
International github repo.
https://github.com/riscv/riscv-gnu-toolchain/tree/rvv-intrinsic
The gcc testcases specifically are here
https://github.com/riscv/riscv-gcc/tree/riscv-gcc-10.1-rvv-dev/gcc/testsuite/gcc.target/riscv/rvv
A lot of the testcases use macros so we can test every variation of an
instruction, and there is a large number of variations for most
instructions, so most of these testcases aren't very readable.  They
are just to verify that we can generate the instructions we expect.
Only the algorithm ones are readable, like saxpy, memcpy, strcpy.

Jim

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 , etc.), if desired.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

[Paul Eggert]

If you're going to document this at all, I suggest documenting 'void' as well as 
'void *', and putting both sets of documentation into the same man page.


For 'void *' you should also mention that one cannot use arithmetic on void * 
pointers, so they're special in that way too. Also, you should warn that because 
one can convert from any pointer type to void * and then to any other pointer 
type, it's a deliberate hole in C's type-checking. It might not also hurt to 
mention 'void const *', 'void volatile *', 'void const volatile *', etc.


For 'void' you can mention the usual things, such as functions returning void, 
and functions declared with (void) parameters, why one would want to cast to 
(void), and so forth.


You're starting to document the C language here, and if you're going to do that 
you might as well do it right.

Re: [PATCH v2 1/4] system_data_types.7: Add int_leastN_t family of types

[Paul Eggert]

On 10/1/20 7:35 AM, Alejandro Colomar via Libc-alpha wrote:

+The narrowest signed integer type
+of a width of at least N bits,


Motivation is missing here. Why is there an int_leastN_t type at all? Also, on 
all glibc platforms, int_leastN_t is equivalent to intN_t; this should probably 
be mentioned.


Similarly for int_fastN_t.

Re: GCC's Git update_hook doesn't support deleting branches

[Joseph Myers]

On Thu, 1 Oct 2020, Jonathan Wakely via Gcc wrote:

> The problem is that the script doesn't check whether the new_object is
> 0.
> 
> I think we want something like this:
> 
> --- update_hook 2020-09-02 23:30:25.074884982 +
> +++ /tmp/update_hook2020-10-01 13:57:14.681656258 +
> @@ -12,6 +12,12 @@
> ref_name = sys.argv[1]
> old_object = sys.argv[2]
> new_object = sys.argv[3]
> +if re.fullmatch('0+', new_object) is not None:
> +if (not ref_name.startswith('refs/users/')
> +and not ref_name.startswith('refs/vendors/')):
> +error('Only personal and vendor branches can be deleted.')
> +sys.exit(1)

The check for which branches can be deleted is handled through the 
restrict-branch-deletion and allow-delete-branch settings.  All you should 
need is to exit early for new_object indicating ref deletion.

(Remember to use --author when committing to the hooks-bin scripts so the 
logs don't show all changes as authored by gccadmin.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC's Git update_hook doesn't support deleting branches

[Jonathan Wakely via Gcc]

On Thu, 1 Oct 2020 at 18:38, Joseph Myers wrote:
>
> On Thu, 1 Oct 2020, Jonathan Wakely via Gcc wrote:
>
> > The problem is that the script doesn't check whether the new_object is
> > 0.
> >
> > I think we want something like this:
> >
> > --- update_hook 2020-09-02 23:30:25.074884982 +
> > +++ /tmp/update_hook2020-10-01 13:57:14.681656258 +
> > @@ -12,6 +12,12 @@
> > ref_name = sys.argv[1]
> > old_object = sys.argv[2]
> > new_object = sys.argv[3]
> > +if re.fullmatch('0+', new_object) is not None:
> > +if (not ref_name.startswith('refs/users/')
> > +and not ref_name.startswith('refs/vendors/')):
> > +error('Only personal and vendor branches can be deleted.')
> > +sys.exit(1)
>
> The check for which branches can be deleted is handled through the
> restrict-branch-deletion and allow-delete-branch settings.  All you should
> need is to exit early for new_object indicating ref deletion.
>
> (Remember to use --author when committing to the hooks-bin scripts so the
> logs don't show all changes as authored by gccadmin.)

Done.

$ git push origin -d refs/users/redi/heads/calendar
To git+ssh://gcc.gnu.org/git/gcc.git
- [deleted] refs/users/redi/heads/calendar

Re: Git rejecting branch merge

[Joel Brobecker]

> I wonder I can get the branch moved, so I can do the benchmarking :)
> Any suggestions how to do that?

Unfortunately, I think the only way (sort of adding the suggested
workaround in the commit-extra-checker script), is to update
the branch directly in the bare repository on sourceware.org.
This would cause the hooks to be by-passed, I believe, so no emails.
If those are desired, and we remember to keep track of the branch's HEAD
before and after, we can call the hook manually to get them sent.

I have login access on the hosting machine, but through an unprivileged
user, so I don't think I can do this for you, unfortunately.

-- 
Joel

GCC PowerPC bootstrap and irange

[David Edelsohn via Gcc]

The latest irange patch has broken bootstrap for PowerPC

In file included from /nasfarm/edelsohn/src/src/gcc/tree-ssa-propagate.h:25:0,
 from
/nasfarm/edelsohn/src/src/gcc/config/rs6000/rs6000-call.c:67:
/nasfarm/edelsohn/src/src/gcc/value-query.h:90:31: error: 'irange' has
not been  declared
   virtual bool range_of_expr (irange &r, tree name, gimple * = NULL) = 0;
   ^~
/nasfarm/edelsohn/src/src/gcc/value-query.h:91:31: error: 'irange' has not been
declared
   virtual bool range_on_edge (irange &r, edge, tree name);
   ^~
/nasfarm/edelsohn/src/src/gcc/value-query.h:92:31: error: 'irange' has not been
declared
   virtual bool range_of_stmt (irange &r, gimple *, tree name = NULL);
   ^~
make[3]: *** [/nasfarm/edelsohn/src/src/gcc/config/rs6000/t-rs6000:47:
rs6000-call.o] Error 1

tree-ssa-propagate.h was (incorrectly?) changed to include
value-query.h, which breaks the flat header model of GCC, but
value-query.h depends upon value-range.h.

rs6000.c includes tree-ssa-propagate.h, but not value-range.h.

GCC sources can't be half pregnant about this.  Either
tree-ssa-propagate.h includes all of the dependent headers or none.  I
thought that the GCC policy was C files including the headers that
they needed, not headers sneaking into other headers.

Thanks, David

gcc-8-20201001 is now available

[GCC Administrator via Gcc]

Snapshot gcc-8-20201001 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20201001/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 42140cb640bd8ab9362d89b8ab01f31309069710

You'll find:

 gcc-8-20201001.tar.xzComplete GCC

  SHA256=06246308fd3f4d843ed6a3f4107ee813dbee716cd25d7bdc39ad85c8a903ecef
  SHA1=fc0c2e820cabbcf27d04eb76c07f88e44dd0aec9

Diffs from 8-20200924 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Git rejecting branch merge

[Joel Brobecker]

> > I wonder I can get the branch moved, so I can do the benchmarking :)
> > Any suggestions how to do that?

I just installed a small patch, hot-fix style which I am hoping will
fix your problem. Can you try it? It passes the testsuite, so the change
should be safe.

Let me know how it goes. I will finish the work over the weekend
so as to replace the local diff by an actual commit (after review
from a coworker of mine).

-- 
Joel