[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241129060857.GH10433@brightrain.aerifal.cx>
Date: Fri, 29 Nov 2024 01:08:58 -0500
From: Rich Felker <dalias@...c.org>
To: Gil Pedersen <kanongil@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: bug: isatty() can return wrong value
On Tue, Nov 26, 2024 at 11:03:36AM +0100, Gil Pedersen wrote:
> > On 20 Aug 2024, at 13.11, Rich Felker <dalias@...c.org> wrote:
> >
> > What guarantee do we have that nothing other than a tty in this state
> > will return EIO for the ioctl? The implementation on the kernel side
> > suggests that, if they tried to put any other device in such a state
> > by replacing its ioctl function the same way, it would also give EIO
> > for these ioctls.
>
> Yeah, EIO is unconditionally signalled for any (expect TIOCSPGRP) ioctl call when a tty is hung.
> While a TIOCGWINSZ ioctl call that returns EIO will very likely be a tty, there is indeed no such guarantee.
>
> > I'm hopeful there's some good fix here where we don't have to have
> > either of these bad behaviors, but returning true for isatty() of a
> > device that is absolutely not a tty is a much worse behavior than
> > returning false for a device that is/was a tty when it was opened but
> > that's been replaced by the kernel with a defunct device.
>
> I have proposed a change to the ioctl handling in the kernel:
>
> https://lore.kernel.org/linux-serial/20241121111506.4717-1-gpdev@gpost.dk/
>
> If merged, the issue should be fixed going forward.
Great. AIUI the proposed kernel change would fix this issue without
needing any further action on the libc side, right?
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.
