[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170406163647.GA2082@port70.net>
Date: Thu, 6 Apr 2017 18:36:47 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT
* 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.
> > 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.
