Re: [PATCH 0/1] linux ttyname{_r}: return ENODEV not ENOENT

[Rich Felker <dalias@libc.org>]

On Thu, Apr 06, 2017 at 06:18:32PM +0200, Szabolcs Nagy wrote:
> * Christian Brauner <christian.brauner@ubuntu.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