public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Zack Weinberg <zackw@panix.com>
Cc: Alejandro Colomar <alx.manpages@gmail.com>,
	linux-man <linux-man@vger.kernel.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [PATCH] Various pages: Remove unused <sys/types.h>
Date: Mon, 15 Mar 2021 18:25:37 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2103151819440.20846@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CAKCAbMiJO8gq7LoDi-iTvmqvDpwUXXnTs8ABHXvin-psyo3+QQ@mail.gmail.com>

On Sun, 14 Mar 2021, Zack Weinberg wrote:

> I endorse this change.  For glibc, if the header file containing the
> function prototype doesn't also provide everything you need to call
> the function, it's a bug (except for a few cases where the relevant
> standards prevent us from doing this, e.g. a function that calls
> vprintf will need the macros in <stdarg.h>, but the C standard
> specifically forbids <stdio.h> to include <stdarg.h>).

And in particular, where older POSIX doesn't require the types used in the 
function declarations to be defined by a header, but permits them to be 
defined by virtue of the general *_t reservation in POSIX (that's not in 
ISO C), it's appropriate to define those types whenever declaring 
functions that use them, rather than only for the newer POSIX versions 
that require those types to be defined alongside declaring the functions 
that use them.  (So we could simplify some of the conditionals in unistd.h 
and remove the "# define uid_t __uid_t" and similar hacks in 
conform/data/unistd.h-data, for example.)

-- 
Joseph S. Myers
joseph@codesourcery.com

  parent reply	other threads:[~2021-03-15 18:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-14 16:01 Alejandro Colomar
2021-03-14 21:40 ` Zack Weinberg
2021-03-14 22:00   ` Michael Kerrisk (man-pages)
2021-03-15 18:25   ` Joseph Myers [this message]
2021-03-19 20:35     ` Alejandro Colomar (man-pages)
2021-03-15  7: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=alpine.DEB.2.22.394.2103151819440.20846@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=alx.manpages@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=zackw@panix.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).