linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
	linux-man <linux-man@vger.kernel.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'
Date: Fri, 2 Oct 2020 15:20:26 +0200	[thread overview]
Message-ID: <63826e82-7a19-0ecc-f73c-56aa560a842f@gmail.com> (raw)
In-Reply-To: <CAH6eHdQrmsHxZbk3+JxRVZ5qH1fhFzLxyigs+DtEzSg2cet+kw@mail.gmail.com>



On 2020-10-02 15:06, Jonathan Wakely wrote:
 > On Fri, 2 Oct 2020 at 12:31, Michael Kerrisk (man-pages)
 > <mtk.manpages@gmail.com> wrote:
 >>
 >> On Fri, 2 Oct 2020 at 12:49, Jonathan Wakely <jwakely.gcc@gmail.com> 
wrote:
 >>>
 >>> On Fri, 2 Oct 2020 at 09:28, Alejandro Colomar via Gcc 
<gcc@gcc.gnu.org> wrote:
 >>>> However, it might be good that someone starts a page called
 >>>> 'type_qualifiers(7)' or something like that.
 >>>
 >>> Who is this for? Who is trying to learn C from man pages? Should
 >>> somebody stop them?
 >>
 >> Yes, I think so. To add context, Alex has been doing a lot of work to
 >> build up the new system_data_types(7) page [1], which I think is
 >> especially useful for the POSIX system data types that are used with
 >> various APIs.
 >
 > It's definitely useful for types like struct siginfo_t and struct
 > timeval, which aren't in C.

Hi Jonathan,

But then the line is a bit diffuse.
Would you document 'ssize_t' and not 'size_t'?
Would you not document intN_t types?
Would you document stdint types, including 'intptr_t', and not 'void *'?

I guess the basic types (int, long, ...) can be left out for now,
and apart from 'int' those rarely are the most appropriate types
for most uses.
But other than that, I would document all of the types.
And even... when all of the other types are documented,
it will be only a little extra effort to document those,
so in the future I might consider that.
But yes, priority should probably go to Linux/POSIX-only types.

Thanks,

Alex

 >
 > Trying to document C seems like a huge task, ill-suited for man-pages,
 > and not worth the effort.
 >
 > Maybe some people prefer man pages, but for everybody else
 > https://en.cppreference.com/w/c already exists and seems like a better
 > use of time.
 >

  reply	other threads:[~2020-10-02 13:20 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 15:06 [PATCH 0/2] Document void * Alejandro Colomar
2020-10-01 15:06 ` [PATCH 1/2] system_data_types.7: Add 'void *' Alejandro Colomar
2020-10-01 15:06 ` [PATCH 2/2] void-*.3: New link to system_data_types(7) Alejandro Colomar
2020-10-01 15:34 ` [PATCH 0/2] Document void * Michael Kerrisk (man-pages)
2020-10-01 15:40   ` Alejandro Colomar
2020-10-01 15:49     ` [PATCH v2 0/2] Document 'void *' Alejandro Colomar
2020-10-01 15:49     ` [PATCH v2 1/2] system_data_types.7: Add " Alejandro Colomar
2020-10-01 16:38       ` Michael Kerrisk (man-pages)
2020-10-01 16:55         ` Alejandro Colomar
2020-10-02 11:54           ` Michael Kerrisk (man-pages)
2020-10-08 13:52           ` Vincent Lefevre
2020-10-12  9:36             ` Michael Kerrisk (man-pages)
2020-10-01 17:32       ` Paul Eggert
2020-10-02  8:24         ` Alejandro Colomar
2020-10-02  8:48           ` Alejandro Colomar
2020-10-02 11:44             ` Michael Kerrisk (man-pages)
2020-10-02  9:10           ` David Laight
2020-10-02 17:00             ` Paul Eggert
2020-10-02 10:49           ` Jonathan Wakely
2020-10-02 11:31             ` Michael Kerrisk (man-pages)
2020-10-02 13:06               ` Jonathan Wakely
2020-10-02 13:20                 ` Alejandro Colomar [this message]
2020-10-02 13:27                   ` Jonathan Wakely
2020-10-02 13:51                     ` Alejandro Colomar
2020-10-03  8:00                       ` Navigational corrections (was: Re: [PATCH v2 1/2] system_data_types.7: Add 'void *') Michael Kerrisk (man-pages)
2020-10-03  9:16                         ` Navigational corrections Alejandro Colomar
2020-10-03 11:39                           ` Michael Kerrisk (man-pages)
2020-10-05 22:08                             ` Alejandro Colomar
2020-10-07  6:53                               ` Michael Kerrisk (man-pages)
2020-10-01 15:49     ` [PATCH v2 2/2] void.3: New link to system_data_types(7) Alejandro Colomar
2020-10-02 13:19     ` [PATCH 0/2] Document void * Jonathan Wakely
2020-10-03 11:44       ` Michael Kerrisk (man-pages)

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=63826e82-7a19-0ecc-f73c-56aa560a842f@gmail.com \
    --to=colomar.6.4.3@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=gcc@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.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).