public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: GNU C Library <libc-alpha@sourceware.org>
Subject: question about Glibc extensions
Date: Wed, 20 May 2020 10:20:23 -0600	[thread overview]
Message-ID: <501e5e0c-f293-b838-5106-764c6b18e061@gmail.com> (raw)

I'm wondering how to go about figuring out what Glibc's expected
behavior is in cases where the standard (e.g., C or POSIX) doesn't
say.  Should the Glibc manual take precedence over the Linux
Programmer's Manual (http://man7.org/linux/man-pages) or should
it be the other way around?

For example, C (and POSIX) requires the first argument to mbstowcs
to be a valid non-null pointer, but the mbstowcs man page says it
can be null.  The Glibc manual doesn't mention it.

Another example is the POSIX readlink function which is required
to set errno to EINVAL if (and only if) the path argument names
a file that is not a symbolic link, but the Linux man page
says it also sets it to EINVAL when the (unsigned) bufsiz
argument is not positive.  The Glibc manual doesn't mention
this behavior.

(Both of these have come up while adding the GCC 10 access attribute
to Glibc's APIs as GCC warns about uses of these extensions.)

Thanks
Martin

PS Where does material for the Linux man pages that describe Glibc
specifics come from?

             reply	other threads:[~2020-05-20 16:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 16:20 Martin Sebor [this message]
2020-05-20 16:38 ` Florian Weimer
2020-05-20 17:30   ` Martin Sebor
2020-05-20 17:32 ` Andreas Schwab
2020-05-20 19:35   ` Martin Sebor
2020-05-20 20:22     ` Andreas Schwab
2020-05-21  1:00       ` Rich Felker
2020-05-21 15:53 ` The GNU C Library Manual - Authoritative or not? Carlos O'Donell
2020-05-21 17:46   ` Martin Sebor
2020-05-21 22:11     ` Carlos O'Donell
2020-05-22  0:22       ` Martin Sebor
2020-05-22 12:35         ` Carlos O'Donell
2020-05-22 21:02           ` Joseph Myers
2020-05-23 20:24             ` Michael Kerrisk
2020-05-25 16:15               ` Carlos O'Donell
2020-05-25  8:58           ` Michael Kerrisk
2020-05-25 15:51             ` J William Piggott
2020-05-25 16:21               ` Carlos O'Donell
2020-05-22  0:20     ` Rich Felker
2020-05-22 10:30       ` Michael Kerrisk
2020-05-22 12:21         ` Carlos O'Donell
2020-05-22 12:54   ` Florian Weimer
2020-05-22 16:23     ` Carlos O'Donell
2020-05-25  9:04     ` Michael Kerrisk
2020-05-25 10:52       ` Florian Weimer
2020-05-25 19:52       ` J William Piggott

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=501e5e0c-f293-b838-5106-764c6b18e061@gmail.com \
    --to=msebor@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /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).