[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170426155259.GY29622@ZenIV.linux.org.uk>
Date: Wed, 26 Apr 2017 16:53:00 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: David Howells <dhowells@...hat.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
Jeff Layton <jlayton@...hat.com>,
lkml <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
linux-man <linux-man@...r.kernel.org>
Subject: Re: Revised statx(2) man page for review [and AT_EMPTY_PATH question]
On Wed, Apr 26, 2017 at 12:35:08PM +0100, David Howells wrote:
> AT_EMPTY_PATH wasn't there back in 2010. I could eliminate the:
>
> statx(fd, NULL, 0, ...);
>
> option in favour of:
>
> statx(fd, "", AT_EMPTY_PATH, ...);
>
> Any thoughts either way, Al?
>
> It would seem that AT_EMPTY_PATH should be redundant, though, since you can
> just set the pathname pointer to NULL.
NULL pathname pointer means an error for a lot of existing syscalls, so
if you want to turn them into wrappers for ...at() ones at libc level,
you'd need to do special-casing of NULL both kernel-side and in libc wrappers.
Requiring "" + AT_EMPTY_PATH means a single dereference of userland pointer.
OTOH, that's not a terrible burden...
Powered by blists - more mailing lists