man/man3type/*: Update history of types A-INTN

aiocb(3type) first appeared in POSIX.1-1996.[1]

[1] ISO/IEC 9945-1:1996, Section 6.7.1.1 "Asynchronous I/O Control Block".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/aiocb.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

man/man3type/aiocb.3type +0 -0

index d81f425fce28..68cefbd0450a 100644

man/man3type/aiocb.3type +0 -0

 .SH SEE ALSO
 .BR aio_cancel (3),
 .BR aio_error (3),

Signature · 1 line

2.47.3

blkcnt_t(3type) and blksize_t(3type) first appeared in SUSv2.[1]

[1] CAE Specification, System Interfaces and Headers, Issue 5, Chapter 4 "Headers", p. 1177.
<https://pubs.opengroup.org/onlinepubs/7908799/xsh/systypes.h.html>

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/blkcnt_t.3type  | 1 +
 man/man3type/blksize_t.3type | 1 +
 2 files changed, 2 insertions(+)

man/man3type/blkcnt_t.3type +1 -0

index 7247f6486b7e..e9644ff94420 100644
@@ -20,6 +20,7 @@ .SH DESCRIPTION
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
+SUSv2,
 POSIX.1-2001.
 .SH NOTES
 The following header also provides this type:

man/man3type/blksize_t.3type +1 -0

index 4ec9013fdb22..81d767d47882 100644
@@ -20,6 +20,7 @@ .SH DESCRIPTION
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
+SUSv2,
 POSIX.1-2001.
 .SH NOTES
 The following header also provides this type:

Signature · 1 line

2.47.3

cc_t(3type), speed_t(3type), and tcflag_t(3type) first appeared in POSIX.1-1988.[1][2]

[1] IEEE Std 1003.1-1988, Section 7.1.2.1 "termios Structure".
[2] IEEE Std 1003.1-1988, Section 7.1.2.7 "Baud Rate Functions".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/cc_t.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

man/man3type/cc_t.3type +1 -1

index 99ed8d4a9ef5..4337d508b8b0 100644
@@ -28,6 +28,6 @@ .SH DESCRIPTION
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
-POSIX.1-2001.
+POSIX.1-1988.
 .SH SEE ALSO
 .BR termios (3)

Signature · 1 line

2.47.3

clockid_t(3type) first appeared in POSIX.1-1996.[1]

[1] ISO/IEC 9945-1:1996, Section 14.1.3 "Type Definitions".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/clockid_t.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

man/man3type/clockid_t.3type +1 -1

index fc44444508f2..62d20c65a5ad 100644
@@ -20,7 +20,7 @@ .SH DESCRIPTION
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
-POSIX.1-2001.
+POSIX.1-1996.
 .SH NOTES
 The following header also provides this type:
 .IR <time.h> .

Signature · 1 line

2.47.3

clock_t(3type) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 2.8.1 "Symbols From The C Standard".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/clock_t.3type | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

man/man3type/clock_t.3type +2 -1

index 6701862d0e8c..93b874f7dfe5 100644
@@ -24,7 +24,8 @@ .SH DESCRIPTION
 .SH STANDARDS
 C11, POSIX.1-2024.
 .SH HISTORY
-C89, POSIX.1-2001.
+C89,
+POSIX.1-1988.
 .SH NOTES
 The following headers also provide this type:
 .I <sys/types.h>

Signature · 1 line

2.47.3

dev_t(3type) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Table 2-1 "Primitive System Data Types".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/dev_t.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

man/man3type/dev_t.3type +1 -1

index 398e6f953015..3bcebcd16191 100644
@@ -22,7 +22,7 @@ .SH DESCRIPTION
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
-POSIX.1-2001.
+POSIX.1-1988.
 .SH NOTES
 The following header also provides this type:
 .IR <sys/stat.h> .

Signature · 1 line

2.47.3

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/div_t.3type | 10 ++++++++++
 1 file changed, 10 insertions(+)

man/man3type/div_t.3type +10 -0

index 19af4ee7d5c3..654e78b215c0 100644
@@ -49,6 +49,16 @@ .SH DESCRIPTION
 .SH STANDARDS
 C11, POSIX.1-2024.
 .SH HISTORY
+.TP
+.I div_t
+.TQ
+.I ldiv_t
+C99,
+POSIX.1-2001.
+.TP
+.I lldiv_t
+.TQ
+.I imaxdiv_t
 C99, POSIX.1-2001.
 .SH SEE ALSO
 .BR div (3),

Signature · 1 line

2.47.3

FILE(3type) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Section 8.2 "FILE-Type C Language Functions".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/FILE.3type | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

man/man3type/FILE.3type +2 -1

index 3adc5f4bc2aa..0c568898333d 100644
@@ -19,7 +19,8 @@ .SH DESCRIPTION
 .SH STANDARDS
 C11, POSIX.1-2024.
 .SH HISTORY
-C89, POSIX.1-2001.
+C89,
+POSIX.1-1988.
 .SH NOTES
 The following header also provides this type:
 .IR <wchar.h> .

Signature · 1 line

2.47.3

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/id_t.3type | 9 +++++++++
 1 file changed, 9 insertions(+)

man/man3type/id_t.3type +9 -0

index 6b17320d96d3..34ea0029b5de 100644
@@ -40,6 +40,15 @@ .SH DESCRIPTION
 .SH STANDARDS
 POSIX.1-2024.
 .SH HISTORY
+.TP
+.I pid_t
+.TQ
+.I uid_t
+.TQ
+.I gid_t
+POSIX.1-2001.
+.TP
+.I id_t
 POSIX.1-2001.
 .SH NOTES
 The following headers also provide

Signature · 1 line

2.47.3

pid_t(3type), uid_t(3type), and gid_t(3type) first appeared in POSIX.1-1988.[1]

[1] IEEE Std 1003.1-1988, Table 2-1 "Primitive System Data Types".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/id_t.3type | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

man/man3type/id_t.3type +1 -1

index 34ea0029b5de..c4b87642c755 100644
@@ -46,7 +46,7 @@ .SH HISTORY
 .I uid_t
 .TQ
 .I gid_t
-POSIX.1-2001.
+POSIX.1-1988.
 .TP
 .I id_t
 POSIX.1-2001.

Signature · 1 line

2.47.3

pid_t(3type), uid_t(3type), and gid_t(3type) were initially not specified as integer types, but as arithmetic types:

"All of the types listed in Table 2-1 shall be arithmetic types; pid_t shall be a signed arithmetic type."[1]

This technically means the types could be floating-point arithmetic types in systems conforming to early versions of POSIX.1.

[1] IEEE Std 1003.1-1988, Section 2.6 "Primitive System Data Types".

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/id_t.3type | 9 +++++++++
 1 file changed, 9 insertions(+)

man/man3type/id_t.3type +9 -0

index c4b87642c755..ad79394b1b72 100644
@@ -50,6 +50,15 @@ .SH HISTORY
 .TP
 .I id_t
 POSIX.1-2001.
+.P
+Initially, POSIX.1-1988 only specified
+.IR pid_t ,
+.IR uid_t ,
+and
+.IR gid_t
+as arithmetic types.
+It was from POSIX.1-2001
+that they were restricted to integer types.
 .SH NOTES
 The following headers also provide
 .IR pid_t :

Signature · 1 line

2.47.3

Quoted 6 lines · Seth McDonald

pid_t(3type), uid_t(3type), and gid_t(3type) were initially not specified as integer types, but as arithmetic types:

"All of the types listed in Table 2-1 shall be arithmetic types; pid_t shall be a signed arithmetic type."[1]

Quoted 2 lines

This technically means the types could be floating-point arithmetic types in systems conforming to early versions of POSIX.1.

But did any implementations do this? As far as I know, there were none, which turns this into something that was only true in paper, and can be entirely ignored.

Hi Seth,

Quoted 6 lines · Seth McDonald

pid_t(3type), uid_t(3type), and gid_t(3type) were initially not specified as integer types, but as arithmetic types:

"All of the types listed in Table 2-1 shall be arithmetic types; pid_t shall be a signed arithmetic type."[1]

Quoted 2 lines

This technically means the types could be floating-point arithmetic types in systems conforming to early versions of POSIX.1.

But did any implementations do this? As far as I know, there were none, which turns this into something that was only true in paper, and can be entirely ignored.

Quoted 9 lines · Alejandro Colomar

Hi Seth,

Quoted 6 lines · Seth McDonald

pid_t(3type), uid_t(3type), and gid_t(3type) were initially not specified as integer types, but as arithmetic types:

"All of the types listed in Table 2-1 shall be arithmetic types; pid_t shall be a signed arithmetic type."[1]

Quoted 6 lines

Quoted 2 lines

This technically means the types could be floating-point arithmetic types in systems conforming to early versions of POSIX.1.

But did any implementations do this? As far as I know, there were none, which turns this into something that was only true in paper, and can be entirely ignored.

While I'm not the most knowledgeable on past implementations, I too can't think of any that used non-integer values for these types. The rationale for them doesn't mention floating-point types,[1] which does suggest there weren't any such implementations to consider.

The purpose of this patch was mainly to document a quirk in the language of early specifications, rather than to imply that such quirky implementations exist and should be accounted for. However, if this isn't appropriate and no such implementations can be found, then I'd agree the paragraph probably shouldn't be added.

----
[1] IEEE Std 1003.1-2024, Volume 4, Appendix B.2.11.1 "Defined Types", p. 3838.
<https://pubs.opengroup.org/onlinepubs/9799919799/xrat/V4_xsh_chap01.html>

----
Seth McDonald.
sethmcmail at pm dot me (mailing lists) 2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/intN_t.3type | 10 ++++++++++
 1 file changed, 10 insertions(+)

man/man3type/intN_t.3type +10 -0

index 8f68aeccee54..5078d0040cfd 100644
@@ -156,6 +156,16 @@ .SH DESCRIPTION
 .SH STANDARDS
 C11, POSIX.1-2024.
 .SH HISTORY
+.TP
+.RI [ u ] int N _t
+C99,
+POSIX.1-2001.
+.TP
+.RB [ U ] INT \f[I]N\f[] _MAX
+.TQ
+.BI INT N _MIN
+.TQ
+.RB [ U ] INT \f[I]N\f[] _C ()
 C99, POSIX.1-2001.
 .P
 The

Signature · 1 line

2.47.3

The [u]intN_t(3type) types, for N ∈ {8,16,32,64}, first appeared in SUSv2 under the <inttypes.h> header.[1]

[1] CAE Specification, System Interfaces and Headers, Issue 5, Chapter 4 "Headers", p. 1089.
<https://pubs.opengroup.org/onlinepubs/7908799/xsh/inttypes.h.html>

Signed-off-by Seth McDonald <[email protected]>

---
 man/man3type/intN_t.3type | 10 ++++++++++
 1 file changed, 10 insertions(+)

man/man3type/intN_t.3type +10 -0

index 5078d0040cfd..8f13bef4f905 100644
@@ -159,6 +159,7 @@ .SH HISTORY
 .TP
 .RI [ u ] int N _t
 C99,
+SUSv2,
 POSIX.1-2001.
 .TP
 .RB [ U ] INT \f[I]N\f[] _MAX

@@ -171,6 +172,15 @@ .SH HISTORY
 The
 .RB [ U ] INT \f[I]N\f[] _WIDTH
 macros were added in C23.
+.P
+Initially, SUSv2 did not include
+.I <stdint.h>
+as a standard header.
+The
+.RI [ u ] int N _t
+types were instead defined in
+.IR <inttypes.h> .
+This was remedied in POSIX.1-2001.
 .SH NOTES
 The following header also provides these types:
 .IR <inttypes.h> .

Signature · 1 line

2.47.3

Hello again!

My next few patch sets should update datatypes in the 3type section. There are 48 patches total for this section, though I will be partitioning them into three separate sets according to alphabetical order. This is primarily based on Linux's documentation recommending patch sets of at most ~15 patches.[1] But if this mailing list has different preferences, let me know and I'll adjust accordingly.

This patch set regards types whose identifiers start with A-INTN (case insensitive, of course).

Regarding the order of the listed standards in HISTORY sections, I've seen man pages with the same set of standards listed in different orders. But I have found a general ordering that a good number of pages adhere to. That being:

SVrX, X.XBSD, SUSvX, POSIX.1-YYYY, POSIX.2, Linux X.X, glibc X.X[.X], others (e.g. OpenBSD, Solaris, AIX).

I call this a 'general' ordering because very rarely (if ever) are all seven standards/systems listed (excluding 'others'). But subsets of them tend to follow their relative ordering above, at least from what I've seen. So for consistency, I tended to use this ordering when adding/updating standards. That is, listing SUS and POSIX.1 after SV and BSD, and before Linux, glibc, and other systems.

I also followed a few more guidelines when editing these lists that may be noteworthy:
- Since POSIX and SUS merged into the same document in POSIX.1-2001/ SUSv3, only POSIX.1-2001 is listed for functions in these standards (or later), but with XSI appended if the function was part of the XSI extension (e.g. POSIX.1-2008 XSI).

- Since SUSv1 is aligned with POSIX.1-1990,[2] if a function's first POSIX appearance was in POSIX.1-1988 or POSIX.1-1990, then it's first appearance in SUSv1 is not also listed due to being implied by its POSIX appearance.

- Similarly, since SUSv2 is aligned with POSIX.1-1996,[3] the same is true for functions first appearing in POSIX.1-1996 and SUSv2.

So in general, SUS is listed if the function (or constant/type) appeared in SUSv1 or SUSv2 before it appeared in POSIX.1.

[1] <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>
[2] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 1.6 "Relationship to Formal Standards", p. 10.

[3] CAE Specification, System Interfaces and Headers, Issue 5, Chapter 1.6 "Relationship to Formal Standards", p. 11.

Seth McDonald (15):
man/man3type/aiocb.3type: HISTORY: Update first POSIX appearance of
aiocb(3type)
man/man3type/blk{cnt,size}_t.3type: HISTORY: Update first SUS
appearance of blk{cnt,size}_t(3type)
man/man3type/cc_t.3type: HISTORY: Update first POSIX appearance of
types
man/man3type/clockid_t.3type: HISTORY: Update first POSIX appearance
of clockid_t(3type)
man/man3type/clock_t.3type: HISTORY: Update first POSIX appearance of

    clock_t(3type)
  man/man3type/dev_t.3type: HISTORY: Update first POSIX appearance of
    dev_t(3type)
  man/man3type/div_t.3type: HISTORY: Split [l]div_t(3type) and
    {ll,imax}div_t(3type)
  man/man3type/div_t.3type: HISTORY: Update first SUS appearance of
    [l]div_t(3type)
  man/man3type/FILE.3type: HISTORY: Update first POSIX appearance of
    FILE(3type)
  man/man3type/id_t.3type: HISTORY: Split id_t(3type) from
    [pug]id_t(3type)

man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of

    [pug]id_t(3type)
  man/man3type/id_t.3type: HISTORY: Mention change in datatypes of
    [pug]id_t(3type)
  man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of
    id_t(3type)
  man/man3type/intN_t.3type: HISTORY: Split types and macros
  man/man3type/intN_t.3type: HISTORY: Update first SUS appearance of
    [u]intN_t(3type)

 man/man3type/FILE.3type      |  3 ++-
 man/man3type/aiocb.3type     |  2 +-
 man/man3type/blkcnt_t.3type  |  1 +
 man/man3type/blksize_t.3type |  1 +
 man/man3type/cc_t.3type      |  2 +-
 man/man3type/clock_t.3type   |  3 ++-
 man/man3type/clockid_t.3type |  2 +-
 man/man3type/dev_t.3type     |  2 +-
 man/man3type/div_t.3type     | 11 +++++++++++
 man/man3type/id_t.3type      | 22 +++++++++++++++++++++-
 man/man3type/intN_t.3type    | 20 ++++++++++++++++++++
 11 files changed, 62 insertions(+), 7 deletions(-)

Range-diff against v0:

 -:  ------------ >  1:  9d2453196924 man/man3type/aiocb.3type: HISTORY: Update first POSIX appearance of aiocb(3type)
 -:  ------------ >  2:  3e3cdf605fad man/man3type/blk{cnt,size}_t.3type: HISTORY: Update first SUS appearance of blk{cnt,size}_t(3type)
 -:  ------------ >  3:  eb523868fce1 man/man3type/cc_t.3type: HISTORY: Update first POSIX appearance of types
 -:  ------------ >  4:  75786342c4cc man/man3type/clockid_t.3type: HISTORY: Update first POSIX appearance of clockid_t(3type)
 -:  ------------ >  5:  24395294f63b man/man3type/clock_t.3type: HISTORY: Update first POSIX appearance of clock_t(3type)
 -:  ------------ >  6:  2bb3f33e65b7 man/man3type/dev_t.3type: HISTORY: Update first POSIX appearance of dev_t(3type)
 -:  ------------ >  7:  417e53f6394a man/man3type/div_t.3type: HISTORY: Split [l]div_t(3type) and {ll,imax}div_t(3type)
 -:  ------------ >  8:  feb8d662b9fe man/man3type/div_t.3type: HISTORY: Update first SUS appearance of [l]div_t(3type)
 -:  ------------ >  9:  77b4c360910f man/man3type/FILE.3type: HISTORY: Update first POSIX appearance of FILE(3type)
 -:  ------------ > 10:  18896b1be985 man/man3type/id_t.3type: HISTORY: Split id_t(3type) from [pug]id_t(3type)
 -:  ------------ > 11:  d32b6148d2a9 man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of [pug]id_t(3type)
 -:  ------------ > 12:  00eec0f9aa43 man/man3type/id_t.3type: HISTORY: Mention change in datatypes of [pug]id_t(3type)
 -:  ------------ > 13:  e5992856df9c man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of id_t(3type)
 -:  ------------ > 14:  903b6a6dee42 man/man3type/intN_t.3type: HISTORY: Split types and macros
 -:  ------------ > 15:  43f013547fbe man/man3type/intN_t.3type: HISTORY: Update first SUS appearance of [u]intN_t(3type)

Signature · 1 line

2.47.3

Hi Seth,

Quoted 8 lines · Seth McDonald

Hello again!

My next few patch sets should update datatypes in the 3type section. There are 48 patches total for this section, though I will be partitioning them into three separate sets according to alphabetical order. This is primarily based on Linux's documentation recommending patch sets of at most ~15 patches.[1] But if this mailing list has different preferences, let me know and I'll adjust accordingly.

We have no bounds on the size of patch sets. On the other hand, it may be good for you not sending a lot of patches that will be rejected due to some small detail, so you may choose to self-restrict to some size. As far as I'm concerned, you could send the 48 patches just fine.

Quoted 10 lines

This patch set regards types whose identifiers start with A-INTN (case insensitive, of course).

Regarding the order of the listed standards in HISTORY sections, I've seen man pages with the same set of standards listed in different orders. But I have found a general ordering that a good number of pages adhere to. That being:

SVrX, X.XBSD, SUSvX, POSIX.1-YYYY, POSIX.2, Linux X.X, glibc X.X[.X], others (e.g. OpenBSD, Solaris, AIX).

I think it would be better to use chronologic order. I leave it up to you if you want to keep the patches as they are, and (optionally) improve the order afterwards, or fix the patches to use chronologic order. Since, as you say, there's no existing consistency, I'll accept the patches in any order; just let me know what you prefer.

Quoted 7 lines

I call this a 'general' ordering because very rarely (if ever) are all seven standards/systems listed (excluding 'others'). But subsets of them tend to follow their relative ordering above, at least from what I've seen. So for consistency, I tended to use this ordering when adding/updating standards. That is, listing SUS and POSIX.1 after SV and BSD, and before Linux, glibc, and other systems.

Quoted 6 lines

I also followed a few more guidelines when editing these lists that may be noteworthy:
- Since POSIX and SUS merged into the same document in POSIX.1-2001/ SUSv3, only POSIX.1-2001 is listed for functions in these standards (or later), but with XSI appended if the function was part of the XSI extension (e.g. POSIX.1-2008 XSI).

LGTM

Quoted 4 lines

- Since SUSv1 is aligned with POSIX.1-1990,[2] if a function's first POSIX appearance was in POSIX.1-1988 or POSIX.1-1990, then it's first appearance in SUSv1 is not also listed due to being implied by its POSIX appearance.

This should be documented in standards(7).

Quoted 2 lines

- Similarly, since SUSv2 is aligned with POSIX.1-1996,[3] the same is true for functions first appearing in POSIX.1-1996 and SUSv2.

This should be documented in standards(7).

Quoted 2 lines

So in general, SUS is listed if the function (or constant/type) appeared in SUSv1 or SUSv2 before it appeared in POSIX.1.

LGTM.

Quoted 3 lines

[1] <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>
[2] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 1.6 "Relationship to Formal Standards", p. 10.

Do you have a link?

Quoted 2 lines

[3] CAE Specification, System Interfaces and Headers, Issue 5, Chapter 1.6 "Relationship to Formal Standards", p. 11.

Do you have a link?

Quoted 22 lines

Seth McDonald (15):
man/man3type/aiocb.3type: HISTORY: Update first POSIX appearance of
aiocb(3type)
man/man3type/blk{cnt,size}_t.3type: HISTORY: Update first SUS
appearance of blk{cnt,size}_t(3type)
man/man3type/cc_t.3type: HISTORY: Update first POSIX appearance of
types
man/man3type/clockid_t.3type: HISTORY: Update first POSIX appearance
of clockid_t(3type)
man/man3type/clock_t.3type: HISTORY: Update first POSIX appearance of

    clock_t(3type)
  man/man3type/dev_t.3type: HISTORY: Update first POSIX appearance of
    dev_t(3type)
  man/man3type/div_t.3type: HISTORY: Split [l]div_t(3type) and
    {ll,imax}div_t(3type)
  man/man3type/div_t.3type: HISTORY: Update first SUS appearance of
    [l]div_t(3type)
  man/man3type/FILE.3type: HISTORY: Update first POSIX appearance of
    FILE(3type)
  man/man3type/id_t.3type: HISTORY: Split id_t(3type) from
    [pug]id_t(3type)

man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of

Quoted 8 lines

    [pug]id_t(3type)
  man/man3type/id_t.3type: HISTORY: Mention change in datatypes of
    [pug]id_t(3type)
  man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of
    id_t(3type)
  man/man3type/intN_t.3type: HISTORY: Split types and macros
  man/man3type/intN_t.3type: HISTORY: Update first SUS appearance of
    [u]intN_t(3type)

I'll ignore all of these patches for now, waiting for your feedback.

Have a lovely day!
Alex

Quoted 33 lines

 man/man3type/FILE.3type      |  3 ++-
 man/man3type/aiocb.3type     |  2 +-
 man/man3type/blkcnt_t.3type  |  1 +
 man/man3type/blksize_t.3type |  1 +
 man/man3type/cc_t.3type      |  2 +-
 man/man3type/clock_t.3type   |  3 ++-
 man/man3type/clockid_t.3type |  2 +-
 man/man3type/dev_t.3type     |  2 +-
 man/man3type/div_t.3type     | 11 +++++++++++
 man/man3type/id_t.3type      | 22 +++++++++++++++++++++-
 man/man3type/intN_t.3type    | 20 ++++++++++++++++++++
 11 files changed, 62 insertions(+), 7 deletions(-)

Range-diff against v0:

 -:  ------------ >  1:  9d2453196924 man/man3type/aiocb.3type: HISTORY: Update first POSIX appearance of aiocb(3type)
 -:  ------------ >  2:  3e3cdf605fad man/man3type/blk{cnt,size}_t.3type: HISTORY: Update first SUS appearance of blk{cnt,size}_t(3type)
 -:  ------------ >  3:  eb523868fce1 man/man3type/cc_t.3type: HISTORY: Update first POSIX appearance of types
 -:  ------------ >  4:  75786342c4cc man/man3type/clockid_t.3type: HISTORY: Update first POSIX appearance of clockid_t(3type)
 -:  ------------ >  5:  24395294f63b man/man3type/clock_t.3type: HISTORY: Update first POSIX appearance of clock_t(3type)
 -:  ------------ >  6:  2bb3f33e65b7 man/man3type/dev_t.3type: HISTORY: Update first POSIX appearance of dev_t(3type)
 -:  ------------ >  7:  417e53f6394a man/man3type/div_t.3type: HISTORY: Split [l]div_t(3type) and {ll,imax}div_t(3type)
 -:  ------------ >  8:  feb8d662b9fe man/man3type/div_t.3type: HISTORY: Update first SUS appearance of [l]div_t(3type)
 -:  ------------ >  9:  77b4c360910f man/man3type/FILE.3type: HISTORY: Update first POSIX appearance of FILE(3type)
 -:  ------------ > 10:  18896b1be985 man/man3type/id_t.3type: HISTORY: Split id_t(3type) from [pug]id_t(3type)
 -:  ------------ > 11:  d32b6148d2a9 man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of [pug]id_t(3type)
 -:  ------------ > 12:  00eec0f9aa43 man/man3type/id_t.3type: HISTORY: Mention change in datatypes of [pug]id_t(3type)
 -:  ------------ > 13:  e5992856df9c man/man3type/id_t.3type: HISTORY: Update first POSIX appearance of id_t(3type)
 -:  ------------ > 14:  903b6a6dee42 man/man3type/intN_t.3type: HISTORY: Split types and macros
 -:  ------------ > 15:  43f013547fbe man/man3type/intN_t.3type: HISTORY: Update first SUS appearance of [u]intN_t(3type)

Signature · 1 line

2.47.3

Signature · 1 line

<https://www.alejandro-colomar.es>

Hi Seth,

On Tue, Jan 06, 2026 at 05:07:49PM +1000, Seth McDonald wrote:

Quoted 5 lines

Regarding the order of the listed standards in HISTORY sections, I've seen man pages with the same set of standards listed in different orders. But I have found a general ordering that a good number of pages adhere to. That being:

Quoted 2 lines

SVrX, X.XBSD, SUSvX, POSIX.1-YYYY, POSIX.2, Linux X.X, glibc X.X[.X], others (e.g. OpenBSD, Solaris, AIX).

I think it would be better to use chronologic order. I leave it up to you if you want to keep the patches as they are, and (optionally) improve the order afterwards, or fix the patches to use chronologic order. Since, as you say, there's no existing consistency, I'll accept the patches in any order; just let me know what you prefer.

Quoted 6 lines

I also followed a few more guidelines when editing these lists that may be noteworthy:
- Since POSIX and SUS merged into the same document in POSIX.1-2001/ SUSv3, only POSIX.1-2001 is listed for functions in these standards (or later), but with XSI appended if the function was part of the XSI extension (e.g. POSIX.1-2008 XSI).

LGTM

Quoted 4 lines

- Since SUSv1 is aligned with POSIX.1-1990,[2] if a function's first POSIX appearance was in POSIX.1-1988 or POSIX.1-1990, then it's first appearance in SUSv1 is not also listed due to being implied by its POSIX appearance.

This should be documented in standards(7).

Quoted 2 lines

- Similarly, since SUSv2 is aligned with POSIX.1-1996,[3] the same is true for functions first appearing in POSIX.1-1996 and SUSv2.

This should be documented in standards(7).

Quoted 2 lines

So in general, SUS is listed if the function (or constant/type) appeared in SUSv1 or SUSv2 before it appeared in POSIX.1.

LGTM.

Quoted 3 lines

[1] https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
[2] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 1.6 "Relationship to Formal Standards", p. 10.

Do you have a link?

Quoted 2 lines

[3] CAE Specification, System Interfaces and Headers, Issue 5, Chapter 1.6 "Relationship to Formal Standards", p. 11.

Do you have a link?

Quoted 3 lines · Alejandro Colomar

Hi Seth,

On Tue, Jan 06, 2026 at 05:07:49PM +1000, Seth McDonald wrote:

[...]

Quoted 5 lines

Quoted 5 lines

Regarding the order of the listed standards in HISTORY sections, I've seen man pages with the same set of standards listed in different orders. But I have found a general ordering that a good number of pages adhere to. That being:

Quoted 8 lines

Quoted 2 lines

SVrX, X.XBSD, SUSvX, POSIX.1-YYYY, POSIX.2, Linux X.X, glibc X.X[.X], others (e.g. OpenBSD, Solaris, AIX).

I think it would be better to use chronologic order. I leave it up to you if you want to keep the patches as they are, and (optionally) improve the order afterwards, or fix the patches to use chronologic order. Since, as you say, there's no existing consistency, I'll accept the patches in any order; just let me know what you prefer.

In that case, I'd much prefer to focus on just adding/adjusting the listed POSIX/SUS standards before polishing their order. I'm also currently not the most informed on the history of BSD and System V, which are both commonly listed in HISTORY sections. So I'd have to first take some time to research on that front.

However, a more efficient method could be someone more knowledgeable than me adjusting the order as I send in patches. That is, I attempt to add POSIX/SUS standards in chronological order, then someone else can adjust the order taking into account the non-POSIX/SUS standards listed. If one is willing, of course.

[...]

Quoted 7 lines

Quoted 6 lines

I also followed a few more guidelines when editing these lists that may be noteworthy:
- Since POSIX and SUS merged into the same document in POSIX.1-2001/ SUSv3, only POSIX.1-2001 is listed for functions in these standards (or later), but with XSI appended if the function was part of the XSI extension (e.g. POSIX.1-2008 XSI).

Quoted 8 lines

LGTM

Quoted 4 lines

- Since SUSv1 is aligned with POSIX.1-1990,[2] if a function's first POSIX appearance was in POSIX.1-1988 or POSIX.1-1990, then it's first appearance in SUSv1 is not also listed due to being implied by its POSIX appearance.

This should be documented in standards(7).

Agreed.

Quoted 4 lines

Quoted 2 lines

- Similarly, since SUSv2 is aligned with POSIX.1-1996,[3] the same is true for functions first appearing in POSIX.1-1996 and SUSv2.

This should be documented in standards(7).

Agreed.

Quoted 10 lines

Quoted 2 lines

So in general, SUS is listed if the function (or constant/type) appeared in SUSv1 or SUSv2 before it appeared in POSIX.1.

LGTM.

Quoted 3 lines

[1] https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
[2] X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2, Chapter 1.6 "Relationship to Formal Standards", p. 10.

Do you have a link?

I don't believe SUSv1 has any online HTML resource. However, its PDFs (one per XPG4v2 volume) are available online. Here's the one for System Interfaces and Headers:
<https://pubs.opengroup.org/onlinepubs/9695969499/toc.pdf>

Quoted 3 lines

Quoted 2 lines

[3] CAE Specification, System Interfaces and Headers, Issue 5, Chapter 1.6 "Relationship to Formal Standards", p. 11.

Quoted 1 line

Do you have a link?

SUSv2 does have an online HTML resource, but I couldn't find the relevant section on it. Fortunately, it does also have PDF versions online. Here's the one for System Interfaces and Headers:
<https://pubs.opengroup.org/onlinepubs/009639399/toc.pdf>

----
Seth McDonald.
sethmcmail at pm dot me (mailing lists) 2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369