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
next prev 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).