[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Apr 2017 18:33:46 +0200
From: Christian Brauner <christian.brauner@...onical.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com,
Christian Brauner <christian.brauner@...ntu.com>, nsz@...t70.net
Subject: Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT
On Thu, Apr 06, 2017 at 12:25:56PM -0400, Rich Felker wrote:
> 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.
This has already been taken care of. :) Michael already merged the patch:
https://www.spinics.net/lists/linux-man/msg11444.html
Christian
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.
