Messages in this thread |  | | | Date | Wed, 8 Apr 2009 16:36:31 +0200 | | From | Ed Schouten <> | | Subject | Inconsistency between PTY read() return values |
| |
Hi all,
Some time ago I noticed this small inconsistency between the return values of read() calls on pseudo-terminal master devices while working on the FreeBSD TTY code.
Consider the following example:
| #include <fcntl.h> | #include <stdio.h> | #include <stdlib.h> | #include <unistd.h> | | int | main(int argc, char *argv[]) | { | int f1, f2; | char buf[20]; | ssize_t r; | | f1 = posix_openpt(O_RDWR|O_NOCTTY); | grantpt(f1); | unlockpt(f1); | | f2 = open(ptsname(f1), O_RDWR); | close(f2); | | r = read(f1, buf, sizeof buf); | printf("%zd\n", r); | if (r == -1) | perror("read"); | | return (0); | }
The code is very simple. It acquires a pseudo-terminal, opens the slave device and closes it. After that it tries to perform a read() on the pseudo-terminal master device. On at least Solaris 7 to 10, Mac OS X 10.5 and FreeBSD 6 to HEAD, this code just prints 0. On Linux (at least 2.6.22-2.6.28) I see the following:
-1 read: Input/output error
I looked through the standards and it seems the POSIX onlinepubs don't mention the behaviour of pseudo-terminal master file descriptors at all. This means it would even be valid of we return 0x1337 or something.
But still, I think it's a little inconsistent. Most programmers would expect pseudo-terminal master file descriptors to behave somewhat similar to TTYs, even though they don't need to be. When you try to perform a read() on the TTY after the master file descriptor gets closed, you get an end-of-file. You only get an EIO when trying to write to this descriptor.
Would it be hard to change the Linux TTY code to behave the same?
-- Ed Schouten <ed@FreeBSD.org> [unhandled content-type:application/pgp-signature] |  |