public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Alejandro Colomar <colomar.6.4.3@gmail.com>
Cc: mtk.manpages@gmail.com, linux-man <linux-man@vger.kernel.org>,
	Florian Weimer <fweimer@redhat.com>
Subject: Re: [IDEA] New pages for types: structs and typedfefs
Date: Sat, 12 Sep 2020 08:33:03 +0200	[thread overview]
Message-ID: <6c5b89f8-4281-4434-cbee-28f88d07920c@gmail.com> (raw)
In-Reply-To: <fb6463f6-49d7-e473-d5e1-1cdf8375e498@gmail.com>

Hi Alex,

On 9/11/20 2:47 PM, Alejandro Colomar wrote:
> Hello Michael,
> 
> In the past, when I was beginning to learn C, I had a lot of trouble 
> with the types.
> 
> When you want to know about a function, you just type 'man function' and 
> that tells you everything you need to know.
> 
> However, when you need to use a type, such as a struct or one of those 
> weird POSIX types (e.g., loff_t), the only solution is to grep through 
> the system headers (e.g., 'cd /usr/include/; grep -rn "struct 
> timespec"'), unless you already know in which man page the type appears.
> 
> I remember well when I wanted to use 'ssize_t' for the first time: it 
> was a nightmare to find which header I had to include to get it.
> 
> Do you agree that it would be a good idea to write man pages for the 
> types, or at least write link pages that link to the page where the type 
> is mentioned?

Your not the first to suggest this. Most recently, if I recall
correctly, Florian also suggested it.

The idea seems reasonable, but I wonder about the best way of doing it.

I propose the desired information for each type would be

* Type name
* Short explanation of the type (often this mcould be just a
  few words, I think)
* Whether the type is specified in POSIX; POSIX requirements on 
  the type.
* Header file that defines the type (in some cases, there 
  may be more than one. This info can be discovered in the
  POSIX spec. (Alex, do you have a PDF of the POSIX spec?)
* Cross references to manual pages of relevant APIs that use the type.

There are some weird corner cases. For example, clock_t:

* times(2): clock_t == clock ticks (sysconf(_SC_CLK_TCK))
* clock(3): clock_t measures in CLOCKS_PER_SEC

Then, do we do one page per type? At first glance, that seems
unwieldy to me. (I could be wrong.) And it seems to me that
there might be benefits in having all of the information in 
one place rather than spread across multiple pages. (For example
cantralizing the info would make it easier for the reader to
get an overview.)

Alternatively, we could have one big page that is a list of the 
types with the above information. Say "system_data_types(7)".
That page might be an alphabetically ordered hanging list of 
entries that look like this:

    timer_t     <time.h> or <sys/types.h>
        POSIX timer ID.

        Conforming to: POSIX.1-2008.

        See: timer_create(2), timer_delete(2), timer_getoverrun(2),
        timer_settime(2)

Then of course, we'd need to have links to that page, so that
people could just type 'man timer_t'. What section should the links
be in? The reasonable candidates would be section 3 or 7. I'm not
yet sure which is better. But the point is that we'd have files 
such as timer_t.3 (or timer_t.7) that are link pages containing the
line:

    .so man7/system_data_types.7

For the moment at least, I'd favor the "one big page plus 
links" approach.

Your thoughts?

Thanks,

Michael

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

  reply	other threads:[~2020-09-12  6:33 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 12:47 [IDEA] New pages for types: structs and typedfefs Alejandro Colomar
2020-09-12  6:33 ` Michael Kerrisk (man-pages) [this message]
2020-09-12  8:59   ` Alejandro Colomar
2020-09-12  9:26     ` Alejandro Colomar
2020-09-13 12:01     ` Michael Kerrisk (man-pages)
2020-09-13 12:53       ` Alejandro Colomar
2020-09-13 20:20         ` Michael Kerrisk (man-pages)
2020-09-13 21:29           ` Alejandro Colomar
2020-09-14  0:20             ` [RFC v1] system_data_types.7: Draft (and links to it: <type>.3) Alejandro Colomar
2020-09-14 10:37               ` Michael Kerrisk (man-pages)
2020-09-14 10:55                 ` Michael Kerrisk (man-pages)
2020-09-22 20:21             ` [IDEA] New pages for types: structs and typedfefs Michael Kerrisk (man-pages)
2020-09-22 20:38               ` Thorsten Glaser
2020-09-23  8:36                 ` Michael Kerrisk (man-pages)
2020-09-23 19:54                   ` Thorsten Glaser
2020-09-14  9:19       ` Jakub Wilk
2020-09-14  9:49         ` Alejandro Colomar
2020-09-18  2:16       ` Guillem Jover
2020-09-19  8:45         ` Michael Kerrisk (man-pages)
2020-09-14 10:22 ` Alejandro Colomar
2020-09-14 14:03   ` [RFC v2] system_data_types.7: Draft v2 Alejandro Colomar
2020-09-14 15:00     ` Michael Kerrisk (man-pages)
2020-09-14 15:52       ` Alejandro Colomar
2020-09-14 19:33         ` Michael Kerrisk (man-pages)
2020-09-15  0:47   ` [RFC v3] sigval.3, ssize_t.3, suseconds_t.3, time_t.3, timer_t.3, timespec.3, timeval.3, system_data_types.7: Document system types (draft v3) Alejandro Colomar
2020-09-15  6:22     ` Michael Kerrisk (man-pages)
2020-09-15 13:33   ` [RFC v4] system_data_types.7: Document sigval, ssize_t, suseconds_t, time_t, timer_t, timespec & timeval Alejandro Colomar
2020-09-15 21:30     ` Michael Kerrisk (man-pages)
2020-09-16  0:59       ` Thorsten Glaser
2020-09-16  8:03         ` Michael Kerrisk (man-pages)
2020-09-16 10:06           ` Andries E. Brouwer
2020-09-16 11:00             ` Michael Kerrisk (man-pages)
2020-09-16 10:52   ` [RFC v5] system_data_types.7: Document types: sigval, ssize_t, suseconds_t, time_t, timer_t, timespec, timeval Alejandro Colomar
2020-09-16 10:56     ` Alejandro Colomar
2020-09-16 11:01   ` [RFC v6] " Alejandro Colomar
2020-09-16 19:24     ` Michael Kerrisk (man-pages)
2020-09-16 19:51       ` Alejandro Colomar
2020-09-16 21:32         ` Thorsten Glaser
2020-09-17  9:23           ` Alejandro Colomar
2020-09-17 10:27         ` Michael Kerrisk (man-pages)
2020-09-17 10:42   ` [PATCH v7 0/8] Document system data types Alejandro Colomar
2020-09-17 21:05     ` Michael Kerrisk (man-pages)
2020-09-17 21:16       ` Alejandro Colomar
2020-09-17 10:42   ` [PATCH v7 1/8] system_data_types.7: Document types: sigval, ssize_t, suseconds_t, time_t, timer_t, timespec, timeval Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 2/8] sigval.3: Add link page Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 3/8] ssize_t.3: " Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 4/8] suseconds_t.3: " Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 5/8] time_t.3: " Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 6/8] timer_t.3: " Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 7/8] timespec.3: " Alejandro Colomar
2020-09-17 10:43   ` [PATCH v7 8/8] timeval.3: " Alejandro Colomar

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=6c5b89f8-4281-4434-cbee-28f88d07920c@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=colomar.6.4.3@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=linux-man@vger.kernel.org \
    /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