> > > > > > ioctl(1, TCGETS, 0xbffff1dc) = -1 EINVAL (Invalid argument)
> > > > > > ioctl(2, TCGETS, 0xbffff1d0) = -1 EINVAL (Invalid argument)
> >
> > Don't you love the way these replies start! Always with "wrong" or "no".
> > The "program" to which you refer is telnetd. The ioctls failed because
> > there were no open fds 1 or 2, yet an open returned 3. Telnetd failed
> > because this was unexpected behavior.
>
> As it happens the "wrong" is precisely the correct answer.
>
> Open returned 3 because fd 1 and 2 are open. The ioctls you quote prove
> that to be true. The error would be different if the the file handle was
> closed. (EBADF)
>
> Alan
>
You presume too much. You presume that the OS was working correctly,
which it is not. Now, in this context, "OS" includes the 'C' runtime
libraries. As previously shown, this problem does not occur with
the glibc libraries on Linux version 2.1.115, however it does occur
with libc-5.3.12 on Linux version 2.1.115.
As previously reported to the glibc folks, glibc allows a write to
a closed file descriptor. It was my understanding that this was
wrong. However, a blow-torch of flames from those folks attempts
to justify this behavior. Therefore, a more salent problem may be
hidden by the glibc hehavior. It would be well for someone to
look into the new pty code to make sure that some problem is not
being hidden in this manner.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.115 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html