[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Apr 2017 12:25:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT
On Thu, Apr 06, 2017 at 06:18:32PM +0200, Szabolcs Nagy wrote:
> * Christian Brauner <christian.brauner@...ntu.com> [2017-04-06 00:32:17 +0200]:
> > After a long struggle we've recently upstreamed a patch to glibc that handles
> > the case where a pts device might not be available even though the corresponding
> > file desciptor refers to a terminal. The classic example is obviously mount
> > namespaces in Linux although this can also be caused by overmounting or other
> > scenarios. While musl correctly detects whether the pts device a given file
> > descriptor refers to can be retrieved it returns ENOENT. We've recently
> > upstreamed a patch to glibc which uses ENODEV. This has been after a discussion
> > about what errno would be most in line with POSIX. Additionally we fixed a bunch
> > of programs to handle the ENODEV case. It would be good if musl would also set
> > ENODEV instead of ENOENT to enable programs to have uniform handle on this case
> > and to minimize the differences between the libcs.
> >
>
> why do applications care about the errno value?
> all they should care about is that there is no
> known tty name if the call failed.
>
> if they really want to look at the errno then
> test for ENOTTY or EBADF (which are specified
> by posix) not for ENODEV (which is not documented
> anywhere and thus is a libc internal detail that
> may change any time in the future).
I think this is a misreading of POSIX. POSIX doesn't allow returning a
standard error for a nonstandard purpose; returning EBADF or ENOTTY
here would clearly be non-conforming since the fd is valid and it's
not a non-tty fd (other functions like isatty will observe it being a
tty). ENOENT is conforming because implementations are allowed to
define their own errors. ENODEV is probably a better choice, though,
since it matches what glibc does.
> aligning musl with glibc makes sense (except of
> course that there might be existing code relying
> on the musl behaviour), but the right way to do
> that is to document the linux specific errno in
> the linux man pages project (then applications
> can justifiably rely on it).
Yes, documenting it there would be a good improvement.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
