linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Alejandro Colomar <colomar.6.4.3@gmail.com>
Cc: mtk.manpages@gmail.com, g.branden.robinson@gmail.com,
	linux-man@vger.kernel.org, libc-alpha@sourceware.org
Subject: Re: [RFC] system_data_types.7: wfix + ffix
Date: Tue, 29 Sep 2020 11:37:21 +0100	[thread overview]
Message-ID: <20200929103719.GJ6642@arm.com> (raw)
In-Reply-To: <20200928151646.20271-1-colomar.6.4.3@gmail.com>

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

  reply	other threads:[~2020-09-29 10:37 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 11:27 [PATCH 0/2] Document size_t Alejandro Colomar
2020-09-18 11:27 ` [PATCH 1/2] system_data_types.7: " Alejandro Colomar
2020-09-18 14:34   ` Florian Weimer
2020-09-18 15:53     ` Alejandro Colomar
2020-09-18 17:27       ` Florian Weimer
2020-09-18 17:42     ` Paul Eggert
2020-09-18 17:53       ` Florian Weimer
2020-09-30 15:50       ` Joseph Myers
2020-09-18 20:13   ` Michael Kerrisk (man-pages)
2020-09-28 13:41   ` Dave Martin
2020-09-28 13:48     ` Alejandro Colomar
2020-09-28 13:55       ` G. Branden Robinson
2020-09-28 14:15         ` Dave Martin
2020-09-28 14:51           ` Alejandro Colomar
2020-09-28 15:16             ` [RFC] system_data_types.7: wfix + ffix Alejandro Colomar
2020-09-29 10:37               ` Dave Martin [this message]
2020-09-29 11:34                 ` Michael Kerrisk (man-pages)
2020-09-29 12:10                   ` Alejandro Colomar
2020-09-29 14:22                     ` [PATCH v2] system_data_types.7: Improve "Include" wording and format, and explain it in NOTES Alejandro Colomar
2020-09-29 14:43                       ` Dave Martin
2020-09-29 14:52                         ` Alejandro Colomar
2020-09-29 15:06                           ` Michael Kerrisk (man-pages)
2020-09-29 15:13                             ` Dave Martin
2020-09-29 15:21                               ` Alejandro Colomar
2020-09-29 15:10                           ` Dave Martin
2020-09-29 11:57                 ` [RFC] system_data_types.7: wfix + ffix Alejandro Colomar
2020-09-30 17:16             ` [PATCH 1/2] system_data_types.7: Document size_t Joseph Myers
2020-09-29 11:11           ` Michael Kerrisk (man-pages)
2020-09-28 14:47         ` Alejandro Colomar
2020-09-18 11:27 ` [PATCH 2/2] size_t.3: New link to new documented type in system_data_types(7) Alejandro Colomar
2020-09-18 20:14   ` Michael Kerrisk (man-pages)
2020-09-18 20:13 ` [PATCH 0/2] Document size_t Michael Kerrisk (man-pages)
2020-09-18 21:28   ` Alejandro Colomar
2020-09-18 21:32     ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200929103719.GJ6642@arm.com \
    --to=dave.martin@arm.com \
    --cc=colomar.6.4.3@gmail.com \
    --cc=g.branden.robinson@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).