public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	linux-man@vger.kernel.org,
	GNU C Library <libc-alpha@sourceware.org>,
	Rich Felker <dalias@libc.org>
Cc: mtk.manpages@gmail.com, nd@arm.com
Subject: Re: glibc and linux-man disagrees about pkey_alloc
Date: Fri, 18 May 2018 15:26:00 -0000	[thread overview]
Message-ID: <ea88be38-f98a-f081-a836-836bbc0a4ea5@gmail.com> (raw)
In-Reply-To: <c3d942a9-ebb7-492f-7c73-af713aed9ac7@arm.com>

On 05/16/2018 01:33 PM, Szabolcs Nagy wrote:
> On 16/05/18 12:19, Dmitry V. Levin wrote:
>> On Wed, May 16, 2018 at 12:10:40PM +0100, Szabolcs Nagy wrote:
>>> glibc sysdeps/unix/sysv/linux/bits/mman-shared.h:
>>>
>>> int pkey_alloc (unsigned int __flags, unsigned int __access_rights) __THROW;
>>>
>>> linux-man http://man7.org/linux/man-pages/man2/pkey_alloc.2.html :
>>>
>>> int pkey_alloc(unsigned long flags, unsigned long access_rights);
>>>
>>> i assume the documentation should be fixed (as the glibc
>>> code is already in use)
>>
>> Note that pkey_alloc syscall takes arguments of type "unsigned long"
>> and explicitly tests them for unsupported bits.
>>
>>
> 
> i see, but this is a general bug in the way the syscalls are
> documented: a syscall is not a c function, so a c declaration
> is not the right way to document it (the pcs does not even
> work for syscalls and the linux uapi headers do not provide
> magic inline wrappers usable from freestanding c code).
> 
> the libc api is in c so that is reasonable to document using
> the c language (using c/posix types).
> 
> so i recommend making the distinction between kernel uapi,
> syscall abi and libc api clear when they disagree about types.
> 
> in this case the man says '#include <sys/mman.h>' which is
> a libc header, so the declaration has to match whatever is
> in there otherwise it's misleading.

In cases like these, the section 2 man pages tend to document
the libc interface. The reason that "unsigned long" was shown
was that until now there was no libc interface. I've amended
the manual page to use "unsigned int" for both arguments.
Thanks for CCing linux-man@

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2018-05-18 15:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16 11:10 Szabolcs Nagy
2018-05-16 11:19 ` Dmitry V. Levin
2018-05-16 11:33   ` Szabolcs Nagy
2018-05-18 15:26     ` Michael Kerrisk (man-pages) [this message]
2018-05-16 14:36 ` Florian Weimer
2018-05-16 15:18   ` Rich Felker

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=ea88be38-f98a-f081-a836-836bbc0a4ea5@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=dalias@libc.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-man@vger.kernel.org \
    --cc=nd@arm.com \
    --cc=szabolcs.nagy@arm.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).