public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>, Zack Weinberg <zackw@panix.com>
Cc: 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: Fri, 19 Mar 2021 21:35:01 +0100	[thread overview]
Message-ID: <574cb3b0-bc99-2c19-2647-566916b9826a@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2103151819440.20846@digraph.polyomino.org.uk>

Hi Joseph,

On 3/15/21 7:25 PM, Joseph Myers wrote:
> 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.)


If you plan to do that (simplify glibc), maybe the changes I'm doing
right now may help you.  It'll take me a few months to complete, but I
plan to further clean the includes in the SYNOPSIS of man[23], so that
only the include that provides the prototype is listed, and if any other
headers are needed, they'll have an explicit comment about why.

After that is merged, you should be able to list all the SYNOPSIS of
man[23] (check our <scripts/bash_aliases> for that) and see which
specify more than one header (and therefore you'll be able to check if a
standard requires it, or if it's a bug in glibc).  I'll CC you both when
I push those changes.

Cheers,

Alex

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2021-03-19 20:35 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
2021-03-19 20:35     ` Alejandro Colomar (man-pages) [this message]
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=574cb3b0-bc99-2c19-2647-566916b9826a@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=joseph@codesourcery.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).