public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Alejandro Colomar <colomar.6.4.3@gmail.com>,
	mtk.manpages@gmail.com, linux-man@vger.kernel.org,
	libc-alpha@sourceware.org
Subject: Re: [PATCH 1/2] system_data_types.7: Document size_t
Date: Mon, 28 Sep 2020 15:15:25 +0100	[thread overview]
Message-ID: <20200928141524.GH6642@arm.com> (raw)
In-Reply-To: <20200928135506.2wsf3cwvkkbreqa3@localhost.localdomain>

On Mon, Sep 28, 2020 at 11:55:08PM +1000, G. Branden Robinson wrote:
> Hi, Alex!
> 
> At 2020-09-28T15:48:14+0200, Alejandro Colomar wrote:
> > > Where does this arbitrary-looking list of headers come from?
> > 
> > There are two parts:  left to the ';', and right to the ';'.
> > 
> > Left: The canonical C standard header, and the canonical POSIX header,
> > in alphabetical order.
> > 
> > Right: All other headers that shall define the header, according to
> > either the C or the POSIX standards, in alphabetical order.

To clarify, does POSIX _guarantee_ that all of those headers define this
type?  (I admit I'm too lazy to search through the POSIX standard for an
answer to this).

If not, this list would serve only to legitimise bad habits and it may
be better to leave it out.


> That's not a bad scheme but it is not inferable from the current man
> page text; I almost commented on the inconsistency in one of my earlier
> messages but deemed it out of scope.  Please document it, perhaps in an
> introductory paragraph at the top of the Description section.

Ack, I think it would be better to state this explicity rather than
having some terse syntax that people need to understand.


IIUC, a program intended to be fully portable between C implementations
must include <stddef.h>, not rely on one of the others.

(In practice it seems reasonable to include any header that is specified
to declare types or function prototypes that themselves require a
definition of size_t, but this is awkward to describe, and not explicit
in the standard.)

[...]

Cheers
---Dave

  reply	other threads:[~2020-09-28 14:15 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 11:27 [PATCH 0/2] " 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 [this message]
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
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=20200928141524.GH6642@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 read-only IMAP folder(s) and NNTP newsgroup(s).