From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>
Subject: Re: Further inconsistencies in FTM
Date: Fri, 8 Jan 2021 12:14:10 +0100 [thread overview]
Message-ID: <cc86ec78-65bd-202f-2704-e551c0442fb9@gmail.com> (raw)
In-Reply-To: <b65f22fe-d30d-c4d3-77e5-29ca7f67d88f@gmail.com>
Hi Michael,
On 1/8/21 11:50 AM, Michael Kerrisk (man-pages) wrote:
> Hi Alex,
>
> On 1/7/21 6:04 PM, Alejandro Colomar (man-pages) wrote:
>> Hi Michael,
>>
>> [[
>> SYNOPSIS
>> #include <stdlib.h>
>>
>> int clearenv(void);
>>
>> Feature Test Macro Requirements for glibc (see fea‐
>> ture_test_macros(7)):
>>
>> clearenv():
>> /* Glibc since 2.19: */ _DEFAULT_SOURCE
>> || /* Glibc <= 2.19: */ _SVID_SOURCE || _BSD_SOURCE
>>
>> ]]
>>
>> [[
>> SYNOPSIS
>> #include <time.h>
>>
>> int dysize(int year);
>>
>> Feature Test Macro Requirements for glibc (see fea‐
>> ture_test_macros(7)):
>>
>> dysize():
>> Since glibc 2.19:
>> _DEFAULT_SOURCE
>> Glibc 2.19 and earlier:
>> _BSD_SOURCE || _SVID_SOURCE
>>
>> ]]
>>
>> Which one do you prefer?
>
> Probably the latter, since it is a little easier to read.
>
> The former form has crept in as a result of my attempts
> to keep the FTM info somewhat compact. See, for example:
>
> chroot():
> Since glibc 2.2.2:
> _XOPEN_SOURCE && ! (_POSIX_C_SOURCE >= 200112L)
> || /* Since glibc 2.20: */ _DEFAULT_SOURCE
> || /* Glibc <= 2.19: */ _BSD_SOURCE
> Before glibc 2.2.2:
> none
>
>
> waitid():
> Since glibc 2.26:
> _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200809L
> Glibc 2.25 and earlier:
> _XOPEN_SOURCE
> || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
> || /* Glibc <= 2.19: */ _BSD_SOURCE
>
> The latter could be rewritten (I hope I got the expansion right)
> as:
> waitid():
> Since glibc 2.26:
> _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200809L
> Glibc 2.20 to 2.25
> _XOPEN_SOURCE || _POSIX_C_SOURCE >= 200809L
> Glibc 2.12 to 2.19
> _XOPEN_SOURCE || _POSIX_C_SOURCE >= 200809L
> || _BSD_SOURCE
> Glibc 2.11 and earlier:
> _XOPEN_SOURCE || _BSD_SOURCE
>
>
> That's more verbose, but perhaps also easier to read, now that
> I look at it.
>
> I'm not sure whether you are thinking of doing some global edit,
> but if you are, perhaps we need to discuss this more.
Well, I'm not thinking of a global edit right now (we've had enough of
those for now I think :), but more as something to think for the future.
So yes, a discussion about if we prefer to have a single way of
expressing FTM or if there are times when the other way is better would
be good.
Your thoughts?
Thanks,
Alex
>
> Thanks,
>
> Michael
>
>
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
next prev parent reply other threads:[~2021-01-08 11:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 17:04 Further inconsistencies in FTM Alejandro Colomar (man-pages)
2021-01-08 10:50 ` Michael Kerrisk (man-pages)
2021-01-08 11:14 ` Alejandro Colomar (man-pages) [this message]
2021-01-08 12:59 ` 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=cc86ec78-65bd-202f-2704-e551c0442fb9@gmail.com \
--to=alx.manpages@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.