public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Rical Jasan <ricaljasan@pacific.net>
To: Joseph Myers <joseph@codesourcery.com>
Cc: libc-alpha@sourceware.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	"Carlos O'Donell" <carlos@redhat.com>
Subject: Re: [PATCH 3/3] manual: Add new header and standards annotations.
Date: Thu, 24 Nov 2016 10:22:00 -0000	[thread overview]
Message-ID: <64fa1a5a-4af3-5e3f-b192-e79203c3e328@pacific.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1611231733010.31292@digraph.polyomino.org.uk>

On 11/23/2016 09:42 AM, Joseph Myers wrote:
> On Tue, 22 Nov 2016, Rical Jasan wrote:
> 
>> 	The "???" placeholder is used for anything not obvious from a
>> 	cursory survey of the glibc sources.
> 
> All argp facilities should be documented as GNU.  Likewise mcheck.h 
> features.  Likewise getauxval.

Thank you!

> The correct standard for posix_fallocate64 is LFS (well, really the 
> combination of both LFS and POSIX.1-2001 enabled, however you denote 
> POSIX.1-2001 && LFS).

OK.

> XOPEN2K is generically an unhelpful name.  In the headers it actually 
> means POSIX.1-2001; the X/Open version is __USE_XOPEN2KXSI.  Likewise 
> __USE_XOPEN2K8 means POSIX.1-2008 and the X/Open version is 
> __USE_XOPEN2K8XSI.  So anywhere you say XOPEN2K because the headers use 
> __USE_XOPEN2K, say POSIX.1-2001 in the manual instead; likewise 
> POSIX.1-2008 for XOPEN2K8.

I'm glad you mention this.  Have you seen the related discussion on
libc-help? [1]  I'm interested in your thoughts on converting standards
to feature test macros (or vice versa).

Also, if we want long-form standards in the manual, where would we put
the feature test macros?  It seems more appropriate to document the
feature test macros in the Summary, and the current framework uses the
standard @comment verbatim there.  (There is also the issue that, e.g.,
XOPEN2K or _USE_XOPEN2K aren't the actual feature test macros one would
even use...)

> strncpy is in ISO C90, one of several standards all commonly shown as 
> "ISO" (though I think "C90", "C99", "C11", "TS 18661-1:2014" etc. might be 
> better names to use - as always, only listing the oldest standard 
> relevant, not later ones that are generally supersets of it).  In stdio.h, 
> SEEK_SET, SEEK_CUR, SEEK_END are all likewise C90.

OK, thank you.

I'll fix these up and wait for other comments.

Rical

[1] https://sourceware.org/ml/libc-help/2016-10/msg00014.html

  reply	other threads:[~2016-11-24 10:22 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23  6:38 [PATCH 0/3] manual: Header & Standards Cleanup Rical Jasan
2016-11-23  6:38 ` [PATCH 3/3] manual: Add new header and standards annotations Rical Jasan
2016-11-23 17:42   ` Joseph Myers
2016-11-24 10:22     ` Rical Jasan [this message]
2016-11-24 13:37       ` Joseph Myers
2016-11-25  5:59         ` Rical Jasan
2016-11-25 14:53           ` Joseph Myers
2016-11-25 15:09             ` Joseph Myers
2016-11-30 10:39             ` Rical Jasan
2016-11-30 10:45               ` Florian Weimer
2016-11-30 12:50                 ` Joseph Myers
2016-12-02 11:54                   ` Rical Jasan
2016-12-02 13:56                     ` Joseph Myers
2016-12-05  7:59                       ` Rical Jasan
2016-11-30 12:38               ` Joseph Myers
2016-12-05  5:33         ` Rical Jasan
2016-12-05 18:22           ` Joseph Myers
2016-12-06 10:57         ` Rical Jasan
2016-12-06 15:59           ` Joseph Myers
2016-12-06 16:36           ` Zack Weinberg
2016-11-25  7:36     ` Rical Jasan
2016-11-25 16:17       ` Joseph Myers
2016-11-30 10:46         ` Rical Jasan
2016-11-30 12:52           ` Joseph Myers
2016-11-23  6:38 ` [PATCH 1/3] manual: Refactor " Rical Jasan
2016-11-23 17:31   ` Joseph Myers
2016-11-24  9:34     ` Rical Jasan
2016-11-24 13:17       ` Joseph Myers
2016-11-25  3:44         ` Rical Jasan
2016-11-25 14:25           ` Joseph Myers
2016-11-30  8:58             ` Rical Jasan
2016-11-23  6:38 ` [PATCH 2/3] manual: Convert @tables of variables to @vtables Rical Jasan

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=64fa1a5a-4af3-5e3f-b192-e79203c3e328@pacific.net \
    --to=ricaljasan@pacific.net \
    --cc=carlos@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.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).