[RFC] system_data_types.7: wfix + ffix

Message ID 20200928151646.20271-1-colomar.6.4.3@gmail.com
State Not applicable
Headers
Series [RFC] system_data_types.7: wfix + ffix |

Commit Message

Alejandro Colomar Sept. 28, 2020, 3:16 p.m. UTC
  The previous format/wording for the includes wasn't very clear.
Improve it a bit following Branden's proposal.

Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
---

Hi,

What do you think about this?

Would you change something?

Thanks,

Alex


 man7/system_data_types.7 | 285 ++++++++++++++++-----------------------
 1 file changed, 113 insertions(+), 172 deletions(-)
  

Comments

Dave Martin Sept. 29, 2020, 10:37 a.m. UTC | #1
On Mon, Sep 28, 2020 at 05:16:47PM +0200, Alejandro Colomar wrote:
> The previous format/wording for the includes wasn't very clear.
> Improve it a bit following Branden's proposal.
> 
> Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
> Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
> ---
> 
> Hi,
> 
> What do you think about this?
> 
> Would you change something?

Why should the user of a man page have to go look at the comments in the
page source in order to find an explanation of what the notation in the
page means?  That seems very strange.

> 
> Thanks,
> 
> Alex
> 
> 
>  man7/system_data_types.7 | 285 ++++++++++++++++-----------------------
>  1 file changed, 113 insertions(+), 172 deletions(-)
> 
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index 16930985e..dc4a3bae4 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -33,20 +33,21 @@ system_data_types \- overview of system data types
>  .\"	Each entry will have the following parts:
>  .\"		* Include
>  .\"			The headers will be in the following order:
> +.\"			"Include:"
>  .\"			1) The main header that shall define the type
> -.\"			   according to the C Standard,
> -.\"			   and
> -.\"			   the main header that shall define the type
> -.\"			   according to POSIX,
> -.\"			   in alphabetical order.
> -.\"			;
> -.\"			2) All other headers that shall define the type
> +.\"			   according to the C Standard.
> +.\"			["or"]
> +.\"			2) The main header that shall define the type
> +.\"			   according to POSIX.
> +.\"			[". Alternatively,"]
> +.\"			3) All other headers that shall define the type
>  .\"			   as described in the previous header(s)
>  .\"			   according to the C Standard or POSIX,
>  .\"			   in alphabetical order.
>  .\"			*) All headers that define the type
>  .\"			   *if* the type is not defined by C nor POSIX,
>  .\"			   in alphabetical order.
> +.\"			"."

It is fine to have notes about page maintenance here -- i.e., which
headers should be placed where in the list, and what order to sort them
in.

However, I think that statements about which header(s) provide the type
under which standard need to be in the actual page text.  Programmers
need this information.

>  .\"
>  .\"		* Definition (no "Definition" header)
>  .\"			Only struct/union types will have definition;
> @@ -203,8 +204,8 @@ See also:
>  .RS
>  .br
>  Include:
> -.IR <stdio.h> ;
> -or
> +.IR <stdio.h> .
> +Alternatively,
>  .IR <wchar.h> .
>  .PP
>  An object type used for streams.
> @@ -268,19 +269,14 @@ type in this page.
>  .RS
>  .br
>  Include:
> -.IR <sys/types.h> ;
> -or
> -.I <grp.h>
> -or
> -.I <pwd.h>
> -or
> -.I <signal.h>
> -or
> -.i <stropts.h>
> -or
> -.I <sys/ipc.h>
> -or
> -.I <sys/stat.h>
> +.IR <sys/types.h> .
> +Alternatively,

How does the reader of the page know that "alternatively" here has a
specific and different meaning from "or"?

Can we describe this somehow along the lines of:

The C standards specify this type in the following header:

	<stddef.h>

In POSIX environments, it is sufficient instead to include any of the
following headers, but the resulting program may not be portable to
other C implementations unless <stddef.h> is also included:

	[etc.]


(I'm not sure this is 100% true, but it seems a safe recommendation.
I'm also being lazy by writing "the C standards" and "POSIX
environments" here -- it would be better to be specific.)

[...]

Cheers
---Dave
  
Michael Kerrisk \(man-pages\) Sept. 29, 2020, 11:34 a.m. UTC | #2
Hi Alex, Dave,

[Alex, just to note: this patch doesn't apply against current master.]

On 9/29/20 12:37 PM, Dave Martin wrote:
> On Mon, Sep 28, 2020 at 05:16:47PM +0200, Alejandro Colomar wrote:
>> The previous format/wording for the includes wasn't very clear.
>> Improve it a bit following Branden's proposal.
>>
>> Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
>> Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
>> ---
>>
>> Hi,
>>
>> What do you think about this?
>>
>> Would you change something?
> 
> Why should the user of a man page have to go look at the comments in the
> page source in order to find an explanation of what the notation in the
> page means?  That seems very strange.

I do agree that we need to add some help for the reader.

Alex, how about we start as follows. At the end of the NOTES Section,
let's add a "Conventions used in this page" subsection (.SS).

Some things to mention there:

* In "Conforming to" we only concern ourselves
  with POSIX.2001 and later and C99 and later.
  The type may be specified in earlier versions
  of one of these standards, but in the interests
  of simplicity we omit details from earlier standards.

* In "Include", we first note the "primary" header(s)
  that define the type according to either the C or POSIX.1
  standards. Under "Alternatively", we note additional headers
  that the standards specify shall define the type.

And then I have a question. Alex, did you so far find a case of
type where the C standard specified that a particular header
shall define the type, but PPOSIX.1 either did not have that
requirement or did not specify that header? I've been kind of
expecting that the set of headers specified by POSIX be a proper 
superset of the the set of headers specified by C, but maybe 
you have found otherwise.

>>  man7/system_data_types.7 | 285 ++++++++++++++++-----------------------
>>  1 file changed, 113 insertions(+), 172 deletions(-)
>>
>> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
>> index 16930985e..dc4a3bae4 100644
>> --- a/man7/system_data_types.7
>> +++ b/man7/system_data_types.7
>> @@ -33,20 +33,21 @@ system_data_types \- overview of system data types
>>  .\"	Each entry will have the following parts:
>>  .\"		* Include
>>  .\"			The headers will be in the following order:
>> +.\"			"Include:"
>>  .\"			1) The main header that shall define the type
>> -.\"			   according to the C Standard,
>> -.\"			   and
>> -.\"			   the main header that shall define the type
>> -.\"			   according to POSIX,
>> -.\"			   in alphabetical order.
>> -.\"			;
>> -.\"			2) All other headers that shall define the type
>> +.\"			   according to the C Standard.
>> +.\"			["or"]
>> +.\"			2) The main header that shall define the type
>> +.\"			   according to POSIX.
>> +.\"			[". Alternatively,"]
>> +.\"			3) All other headers that shall define the type
>>  .\"			   as described in the previous header(s)
>>  .\"			   according to the C Standard or POSIX,
>>  .\"			   in alphabetical order.
>>  .\"			*) All headers that define the type
>>  .\"			   *if* the type is not defined by C nor POSIX,
>>  .\"			   in alphabetical order.
>> +.\"			"."
> 
> It is fine to have notes about page maintenance here -- i.e., which
> headers should be placed where in the list, and what order to sort them
> in.
> 
> However, I think that statements about which header(s) provide the type
> under which standard need to be in the actual page text.  Programmers
> need this information.

My question (to Alex) above is related. (And to repeat, the thing
I most care about in the man pages is POSIX.1, rather than C.)

>>  .\"
>>  .\"		* Definition (no "Definition" header)
>>  .\"			Only struct/union types will have definition;
>> @@ -203,8 +204,8 @@ See also:
>>  .RS
>>  .br
>>  Include:
>> -.IR <stdio.h> ;
>> -or
>> +.IR <stdio.h> .
>> +Alternatively,
>>  .IR <wchar.h> .
>>  .PP
>>  An object type used for streams.
>> @@ -268,19 +269,14 @@ type in this page.
>>  .RS
>>  .br
>>  Include:
>> -.IR <sys/types.h> ;
>> -or
>> -.I <grp.h>
>> -or
>> -.I <pwd.h>
>> -or
>> -.I <signal.h>
>> -or
>> -.i <stropts.h>
>> -or
>> -.I <sys/ipc.h>
>> -or
>> -.I <sys/stat.h>
>> +.IR <sys/types.h> .
>> +Alternatively,
> 
> How does the reader of the page know that "alternatively" here has a
> specific and different meaning from "or"?
> 
> Can we describe this somehow along the lines of:
> 
> The C standards specify this type in the following header:
> 
> 	<stddef.h>
> 
> In POSIX environments, it is sufficient instead to include any of the
> following headers, but the resulting program may not be portable to
> other C implementations unless <stddef.h> is also included:
> 
> 	[etc.]
> 
> 
> (I'm not sure this is 100% true, but it seems a safe recommendation.
> I'm also being lazy by writing "the C standards" and "POSIX
> environments" here -- it would be better to be specific.)

This feels too verbose to me. Again, I care more about POSIX
than C here. This is Linux; it quacks like a UNIX; so POSIX
is the most relevant thing. And I want to keep the discussion
of these types reasonably brief. In particular, I think that
people who care a lot about portability across C implementations
need to be looking somewhere else than the Linux manual pages.

Thanks,

Michael
  
Alejandro Colomar Sept. 29, 2020, 11:57 a.m. UTC | #3
Hi Dave,

On 2020-09-29 12:37, Dave Martin wrote:
> On Mon, Sep 28, 2020 at 05:16:47PM +0200, Alejandro Colomar wrote:
>> The previous format/wording for the includes wasn't very clear.
>> Improve it a bit following Branden's proposal.
>>
>> Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
>> Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
>> ---
>>
>> Hi,
>>
>> What do you think about this?
>>
>> Would you change something?
> 
> Why should the user of a man page have to go look at the comments in the
> page source in order to find an explanation of what the notation in the
> page means?  That seems very strange.

I think I'll add a paragraph in the NOTES section at the bottom of the page.

> 
>>
>> Thanks,
>>
>> Alex
>>
>>
>>   man7/system_data_types.7 | 285 ++++++++++++++++-----------------------
>>   1 file changed, 113 insertions(+), 172 deletions(-)
>>
>> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
>> index 16930985e..dc4a3bae4 100644
>> --- a/man7/system_data_types.7
>> +++ b/man7/system_data_types.7
>> @@ -33,20 +33,21 @@ system_data_types \- overview of system data types
>>   .\"	Each entry will have the following parts:
>>   .\"		* Include
>>   .\"			The headers will be in the following order:
>> +.\"			"Include:"
>>   .\"			1) The main header that shall define the type
>> -.\"			   according to the C Standard,
>> -.\"			   and
>> -.\"			   the main header that shall define the type
>> -.\"			   according to POSIX,
>> -.\"			   in alphabetical order.
>> -.\"			;
>> -.\"			2) All other headers that shall define the type
>> +.\"			   according to the C Standard.
>> +.\"			["or"]
>> +.\"			2) The main header that shall define the type
>> +.\"			   according to POSIX.
>> +.\"			[". Alternatively,"]
>> +.\"			3) All other headers that shall define the type
>>   .\"			   as described in the previous header(s)
>>   .\"			   according to the C Standard or POSIX,
>>   .\"			   in alphabetical order.
>>   .\"			*) All headers that define the type
>>   .\"			   *if* the type is not defined by C nor POSIX,
>>   .\"			   in alphabetical order.
>> +.\"			"."
> 
> It is fine to have notes about page maintenance here -- i.e., which
> headers should be placed where in the list, and what order to sort them
> in.
> 
> However, I think that statements about which header(s) provide the type
> under which standard need to be in the actual page text.  Programmers
> need this information.

I hope a paragraph in the NOTES section will be explicit enough, as said 
above.

> 
>>   .\"
>>   .\"		* Definition (no "Definition" header)
>>   .\"			Only struct/union types will have definition;
>> @@ -203,8 +204,8 @@ See also:
>>   .RS
>>   .br
>>   Include:
>> -.IR <stdio.h> ;
>> -or
>> +.IR <stdio.h> .
>> +Alternatively,
>>   .IR <wchar.h> .
>>   .PP
>>   An object type used for streams.
>> @@ -268,19 +269,14 @@ type in this page.
>>   .RS
>>   .br
>>   Include:
>> -.IR <sys/types.h> ;
>> -or
>> -.I <grp.h>
>> -or
>> -.I <pwd.h>
>> -or
>> -.I <signal.h>
>> -or
>> -.i <stropts.h>
>> -or
>> -.I <sys/ipc.h>
>> -or
>> -.I <sys/stat.h>
>> +.IR <sys/types.h> .
>> +Alternatively,
> 
> How does the reader of the page know that "alternatively" here has a
> specific and different meaning from "or"?

Well, it remarks a bit that those are something like 2nd class headers 
for that definition.  But that together with a paragraph in NOTES will 
be better.

> 
> Can we describe this somehow along the lines of:
> 
> The C standards specify this type in the following header:
> 
> 	<stddef.h>
> 
> In POSIX environments, it is sufficient instead to include any of the
> following headers, but the resulting program may not be portable to
> other C implementations unless <stddef.h> is also included:
> 
> 	[etc.]
> 
> 
> (I'm not sure this is 100% true, but it seems a safe recommendation.
> I'm also being lazy by writing "the C standards" and "POSIX
> environments" here -- it would be better to be specific.)
> 
> [...]

I wanted to avoid that because that would add a lot of noise lines.

Do you think the note in NOTES would be enough?

Thanks,

Alex

> 
> Cheers
> ---Dave
>
  
Alejandro Colomar Sept. 29, 2020, 12:10 p.m. UTC | #4
Hi Michael & Dave,

On 2020-09-29 13:34, Michael Kerrisk (man-pages) wrote:
 > Hi Alex, Dave,
 >
 > [Alex, just to note: this patch doesn't apply against current master.]
 >
 > On 9/29/20 12:37 PM, Dave Martin wrote:
 >> On Mon, Sep 28, 2020 at 05:16:47PM +0200, Alejandro Colomar wrote:
 >>> The previous format/wording for the includes wasn't very clear.
 >>> Improve it a bit following Branden's proposal.
 >>>
 >>> Reported-by: G. Branden Robinson <g.branden.robinson@gmail.com>
 >>> Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
 >>> ---
 >>>
 >>> Hi,
 >>>
 >>> What do you think about this?
 >>>
 >>> Would you change something?
 >>
 >> Why should the user of a man page have to go look at the comments in the
 >> page source in order to find an explanation of what the notation in the
 >> page means?  That seems very strange.
 >
 > I do agree that we need to add some help for the reader.
 >
 > Alex, how about we start as follows. At the end of the NOTES Section,
 > let's add a "Conventions used in this page" subsection (.SS).

I just sent an email I wrote an hour ago,
where I proposed to add a paragraph in NOTES.
Your proposal is a bit more specific :)

 >
 > Some things to mention there:
 >
 > * In "Conforming to" we only concern ourselves
 >    with POSIX.2001 and later and C99 and later.
 >    The type may be specified in earlier versions
 >    of one of these standards, but in the interests
 >    of simplicity we omit details from earlier standards.

Agree.

 >
 > * In "Include", we first note the "primary" header(s)
 >    that define the type according to either the C or POSIX.1
 >    standards. Under "Alternatively", we note additional headers
 >    that the standards specify shall define the type.

Agree.

 >
 > And then I have a question. Alex, did you so far find a case of
 > type where the C standard specified that a particular header
 > shall define the type, but PPOSIX.1 either did not have that
 > requirement or did not specify that header?

No.

I've found types where the "primary" header is different in C and POSIX.
But in all the cases I've checked, POSIX always adds headers to C,
and never removes them.
I hope it is always true, because I didn't check all of them one by one.

 > I've been kind of
 > expecting that the set of headers specified by POSIX be a proper
 > superset of the the set of headers specified by C, but maybe
 > you have found otherwise.

AFAICS, that holds true.

 >
 >>>   man7/system_data_types.7 | 285 
++++++++++++++++-----------------------
 >>>   1 file changed, 113 insertions(+), 172 deletions(-)
 >>>
 >>> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
 >>> index 16930985e..dc4a3bae4 100644
 >>> --- a/man7/system_data_types.7
 >>> +++ b/man7/system_data_types.7
 >>> @@ -33,20 +33,21 @@ system_data_types \- overview of system data types
 >>>   .\"	Each entry will have the following parts:
 >>>   .\"		* Include
 >>>   .\"			The headers will be in the following order:
 >>> +.\"			"Include:"
 >>>   .\"			1) The main header that shall define the type
 >>> -.\"			   according to the C Standard,
 >>> -.\"			   and
 >>> -.\"			   the main header that shall define the type
 >>> -.\"			   according to POSIX,
 >>> -.\"			   in alphabetical order.
 >>> -.\"			;
 >>> -.\"			2) All other headers that shall define the type
 >>> +.\"			   according to the C Standard.
 >>> +.\"			["or"]
 >>> +.\"			2) The main header that shall define the type
 >>> +.\"			   according to POSIX.
 >>> +.\"			[". Alternatively,"]
 >>> +.\"			3) All other headers that shall define the type
 >>>   .\"			   as described in the previous header(s)
 >>>   .\"			   according to the C Standard or POSIX,
 >>>   .\"			   in alphabetical order.
 >>>   .\"			*) All headers that define the type
 >>>   .\"			   *if* the type is not defined by C nor POSIX,
 >>>   .\"			   in alphabetical order.
 >>> +.\"			"."
 >>
 >> It is fine to have notes about page maintenance here -- i.e., which
 >> headers should be placed where in the list, and what order to sort them
 >> in.
 >>
 >> However, I think that statements about which header(s) provide the type
 >> under which standard need to be in the actual page text.  Programmers
 >> need this information.
 >
 > My question (to Alex) above is related. (And to repeat, the thing
 > I most care about in the man pages is POSIX.1, rather than C.)

If/when the NOTES section documents that clearly,
I may remove that comment.

 >
 >>>   .\"
 >>>   .\"		* Definition (no "Definition" header)
 >>>   .\"			Only struct/union types will have definition;
 >>> @@ -203,8 +204,8 @@ See also:
 >>>   .RS
 >>>   .br
 >>>   Include:
 >>> -.IR <stdio.h> ;
 >>> -or
 >>> +.IR <stdio.h> .
 >>> +Alternatively,
 >>>   .IR <wchar.h> .
 >>>   .PP
 >>>   An object type used for streams.
 >>> @@ -268,19 +269,14 @@ type in this page.
 >>>   .RS
 >>>   .br
 >>>   Include:
 >>> -.IR <sys/types.h> ;
 >>> -or
 >>> -.I <grp.h>
 >>> -or
 >>> -.I <pwd.h>
 >>> -or
 >>> -.I <signal.h>
 >>> -or
 >>> -.i <stropts.h>
 >>> -or
 >>> -.I <sys/ipc.h>
 >>> -or
 >>> -.I <sys/stat.h>
 >>> +.IR <sys/types.h> .
 >>> +Alternatively,
 >>
 >> How does the reader of the page know that "alternatively" here has a
 >> specific and different meaning from "or"?
 >>
 >> Can we describe this somehow along the lines of:
 >>
 >> The C standards specify this type in the following header:
 >>
 >> 	<stddef.h>
 >>
 >> In POSIX environments, it is sufficient instead to include any of the
 >> following headers, but the resulting program may not be portable to
 >> other C implementations unless <stddef.h> is also included:
 >>
 >> 	[etc.]
 >>
 >>
 >> (I'm not sure this is 100% true, but it seems a safe recommendation.
 >> I'm also being lazy by writing "the C standards" and "POSIX
 >> environments" here -- it would be better to be specific.)
 >
 > This feels too verbose to me. Again, I care more about POSIX
 > than C here. This is Linux; it quacks like a UNIX; so POSIX
 > is the most relevant thing. And I want to keep the discussion
 > of these types reasonably brief. In particular, I think that
 > people who care a lot about portability across C implementations
 > need to be looking somewhere else than the Linux manual pages.

Agree,

 >
 > Thanks,
 >
 > Michael
 >

Thanks,

Alex
  

Patch

diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index 16930985e..dc4a3bae4 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -33,20 +33,21 @@  system_data_types \- overview of system data types
 .\"	Each entry will have the following parts:
 .\"		* Include
 .\"			The headers will be in the following order:
+.\"			"Include:"
 .\"			1) The main header that shall define the type
-.\"			   according to the C Standard,
-.\"			   and
-.\"			   the main header that shall define the type
-.\"			   according to POSIX,
-.\"			   in alphabetical order.
-.\"			;
-.\"			2) All other headers that shall define the type
+.\"			   according to the C Standard.
+.\"			["or"]
+.\"			2) The main header that shall define the type
+.\"			   according to POSIX.
+.\"			[". Alternatively,"]
+.\"			3) All other headers that shall define the type
 .\"			   as described in the previous header(s)
 .\"			   according to the C Standard or POSIX,
 .\"			   in alphabetical order.
 .\"			*) All headers that define the type
 .\"			   *if* the type is not defined by C nor POSIX,
 .\"			   in alphabetical order.
+.\"			"."
 .\"
 .\"		* Definition (no "Definition" header)
 .\"			Only struct/union types will have definition;
@@ -203,8 +204,8 @@  See also:
 .RS
 .br
 Include:
-.IR <stdio.h> ;
-or
+.IR <stdio.h> .
+Alternatively,
 .IR <wchar.h> .
 .PP
 An object type used for streams.
@@ -268,19 +269,14 @@  type in this page.
 .RS
 .br
 Include:
-.IR <sys/types.h> ;
-or
-.I <grp.h>
-or
-.I <pwd.h>
-or
-.I <signal.h>
-or
-.I <stropts.h>
-or
-.I <sys/ipc.h>
-or
-.I <sys/stat.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <grp.h> ,
+.IR <pwd.h> ,
+.IR <signal.h> ,
+.IR <stropts.h> ,
+.IR <sys/ipc.h> ,
+.IR <sys/stat.h> ,
 or
 .IR <unistd.h> .
 .PP
@@ -305,8 +301,8 @@  See also:
 .RS
 .br
 Include:
-.IR <sys/types.h> ;
-or
+.IR <sys/types.h> .
+Alternatively,
 .IR <sys/resource.h> .
 .PP
 A type used to hold a general identifier.
@@ -450,29 +446,19 @@  See also:
 .RS
 .br
 Include
-.IR <sys/types.h> ;
-or
-.I <fcntl.h>
-or
-.I <sched.h>
-or
-.I <signal.h>
-or
-.I <spawn.h>
-or
-.I <sys/msg.h>
-or
-.I <sys/sem.h>
-or
-.I <sys/shm.h>
-or
-.I <sys/wait.h>
-or
-.I <termios.h>
-or
-.I <time.h>
-or
-.I <unistd.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <fcntl.h> ,
+.IR <sched.h> ,
+.IR <signal.h> ,
+.IR <spawn.h> ,
+.IR <sys/msg.h> ,
+.IR <sys/sem.h> ,
+.IR <sys/shm.h> ,
+.IR <sys/wait.h> ,
+.IR <termios.h> ,
+.IR <time.h> ,
+.IR <unistd.h> ,
 or
 .IR <utmpx.h> .
 .PP
@@ -602,11 +588,10 @@  types in this page.
 .RS
 .br
 Include:
-.IR <signal.h> ;
-or
-.I <aio.h>
-or
-.I <mqueue.h>
+.IR <signal.h> .
+Alternatively,
+.IR <aio.h> ,
+.IR <mqueue.h> ,
 or
 .IR <time.h> .
 .PP
@@ -651,8 +636,8 @@  structure in this page.
 .RS
 .br
 Include:
-.IR <signal.h> ;
-or
+.IR <signal.h> .
+Alternatively,
 .IR <sys/wait.h> .
 .PP
 .EX
@@ -687,9 +672,9 @@  See also:
 .RS
 .br
 Include:
-.IR <signal.h> ;
-or
-.I <spawn.h>
+.IR <signal.h> .
+Alternatively,
+.IR <spawn.h> ,
 or
 .IR <sys/select.h> .
 .PP
@@ -750,55 +735,32 @@  in this page.
 Include:
 .I <stddef.h>
 or
-.IR <sys/types.h> ;
-or
-.I <aio.h>
-or
-.I <glob.h>
-or
-.I <grp.h>
-or
-.I <iconv.h>
-or
-.I <monetary.h>
-or
-.I <mqueue.h>
-or
-.I <ndbm.h>
-or
-.I <pwd.h>
-or
-.I <regex.h>
-or
-.I <search.h>
-or
-.I <signal.h>
-or
-.I <stdio.h>
-or
-.I <stdlib.h>
-or
-.I <string.h>
-or
-.I <strings.h>
-or
-.I <sys/mman.h>
-or
-.I <sys/msg.h>
-or
-.I <sys/sem.h>
-or
-.I <sys/shm.h>
-or
-.I <sys/socket.h>
-or
-.I <sys/uio.h>
-or
-.I <time.h>
-or
-.I <unistd.h>
-or
-.I <wchar.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <aio.h> ,
+.IR <glob.h> ,
+.IR <grp.h> ,
+.IR <iconv.h> ,
+.IR <monetary.h> ,
+.IR <mqueue.h> ,
+.IR <ndbm.h> ,
+.IR <pwd.h> ,
+.IR <regex.h> ,
+.IR <search.h> ,
+.IR <signal.h> ,
+.IR <stdio.h> ,
+.IR <stdlib.h> ,
+.IR <string.h> ,
+.IR <strings.h> ,
+.IR <sys/mman.h> ,
+.IR <sys/msg.h> ,
+.IR <sys/sem.h> ,
+.IR <sys/shm.h> ,
+.IR <sys/socket.h> ,
+.IR <sys/uio.h> ,
+.IR <time.h> ,
+.IR <unistd.h> ,
+.IR <wchar.h> ,
 or
 .IR <wordexp.h> .
 .PP
@@ -871,21 +833,15 @@  types in this page.
 .RS
 .br
 Include:
-.IR <sys/types.h> ;
-or
-.I <aio.h>
-or
-.I <monetary.h>
-or
-.I <mqueue.h>
-or
-.I <stdio.h>
-or
-.I <sys/msg.h>
-or
-.I <sys/socket.h>
-or
-.I <sys/uio.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <aio.h> ,
+.IR <monetary.h> ,
+.IR <mqueue.h> ,
+.IR <stdio.h> ,
+.IR <sys/msg.h> ,
+.IR <sys/socket.h> ,
+.IR <sys/uio.h> ,
 or
 .IR <unistd.h> .
 .PP
@@ -947,9 +903,9 @@  types in this page.
 .RS
 .br
 Include:
-.IR <sys/types.h> ;
-or
-.I <sys/select.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <sys/select.h> ,
 or
 .IR <sys/time.h> .
 .PP
@@ -974,23 +930,17 @@  structure in this page.
 .RS
 .br
 Include:
-.I <sys/types.h>
-or
-.IR <time.h> ;
-or
-.I <sched.h>
-or
-.I <sys/msg.h>
-or
-.I <sys/select.h>
-or
-.I <sys/sem.h>
-or
-.I <sys/shm.h>
-or
-.I <sys/stat.h>
+.I <time.h>
 or
-.I <sys/time.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <sched.h> ,
+.IR <sys/msg.h> ,
+.IR <sys/select.h> ,
+.IR <sys/sem.h> ,
+.IR <sys/shm.h> ,
+.IR <sys/stat.h> ,
+.IR <sys/time.h> ,
 or
 .IR <utime.h> .
 .PP
@@ -1017,8 +967,8 @@  See also:
 .RS
 .br
 Include:
-.IR <sys/types.h> ;
-or
+.IR <sys/types.h> .
+Alternatively,
 .IR <time.h> .
 .PP
 Used for timer ID returned by
@@ -1040,17 +990,13 @@  See also:
 .RS
 .br
 Include:
-.IR <time.h> ;
-or
-.I <aio.h>
-or
-.I <mqueue.h>
-or
-.I <sched.h>
-or
-.I <signal.h>
-or
-.I <sys/select.h>
+.IR <time.h> .
+Alternatively,
+.IR <aio.h> ,
+.IR <mqueue.h> ,
+.IR <sched.h> ,
+.IR <signal.h> ,
+.IR <sys/select.h> ,
 or
 .IR <sys/stat.h> .
 .PP
@@ -1078,11 +1024,10 @@  See also:
 .RS
 .br
 Include:
-.IR <sys/time.h> ;
-or
-.I <sys/resource.h>
-or
-.I <sys/select.h>
+.IR <sys/time.h> .
+Alternatively,
+.IR <sys/resource.h> ,
+.IR <sys/select.h> ,
 or
 .IR <utmpx.h> .
 .PP
@@ -1111,17 +1056,13 @@  See also:
 .RS
 .br
 Include:
-.IR <sys/types.h> ;
-or
-.I <pwd.h>
-or
-.I <signal.h>
-or
-.I <stropts.h>
-or
-.I <sys/ipc.h>
-or
-.I <sys/stat.h>
+.IR <sys/types.h> .
+Alternatively,
+.IR <pwd.h> ,
+.IR <signal.h> ,
+.IR <stropts.h> ,
+.IR <sys/ipc.h> ,
+.IR <sys/stat.h> ,
 or
 .IR <unistd.h> .
 .PP
@@ -1145,9 +1086,9 @@  See also:
 .RS
 .br
 Include:
-.IR <stdarg> ;
-or
-.I <stdio.h>
+.IR <stdarg> .
+Alternatively,
+.IR <stdio.h> ,
 or
 .IR <wchar.h> .
 .PP