[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170406170222.GO17319@brightrain.aerifal.cx>
Date: Thu, 6 Apr 2017 13:02:22 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com,
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:36:47PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2017-04-06 12:25:56 -0400]:
>
> > 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.
> >
>
> i didnt say the libc code should be changed, but
> that applications should test for EBADF or ENOTTY
> and if they find something else then assume something
> else was the problem instead of checking something
> undocumented and make assumptions based on that.
Yes, I think that's correct. Or even just assume the error is always
something else. EBADF can never happen without a buggy program, and if
you already know the fd is a tty, ENOTTY can't happen either, so
there's probably no reason to handle these two.
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.
