Inconsistency between PTY read() return values

Inconsistency between PTY read() return values

[Ed Schouten]

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

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>

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

Re: Inconsistency between PTY read() return values

[Alan Cox]

> 	-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

I would argue that TTYs do behave this way. We treat the disconnect as a
hang up event. BSD sees it as EOF, Linux as hangup.

> 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?

Probably not vastly so, but given it has been this way for over ten years
and causes no problems I don't think it makes sense to do so.

Alan

Re: Inconsistency between PTY read() return values

[Ed Schouten]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

Hi Alan,

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> I would argue that TTYs do behave this way. We treat the disconnect as a
> hang up event. BSD sees it as EOF, Linux as hangup.

Would you mind explaining me the difference? I thought a modem
disconnect implies an end-of-file condition? If you take the code I
mentioned and modify it to close the master device and perform a read on
the TTY, it will return 0.

-- 
 Ed Schouten <ed@FreeBSD.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

Re: Inconsistency between PTY read() return values

[Alan Cox]

On Wed, 8 Apr 2009 19:56:03 +0200
Ed Schouten <ed@FreeBSD.org> wrote:

> Hi Alan,
> 
> * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > I would argue that TTYs do behave this way. We treat the disconnect as a
> > hang up event. BSD sees it as EOF, Linux as hangup.
> 
> Would you mind explaining me the difference? I thought a modem
> disconnect implies an end-of-file condition? 

A modem disconnect is a hang up which is quite different to an EOF and is
effectively a security barrier as well (existing users of the tty port
lose access to it aka revoke())

Re: Inconsistency between PTY read() return values

[Ed Schouten]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> A modem disconnect is a hang up which is quite different to an EOF and is
> effectively a security barrier as well (existing users of the tty port
> lose access to it aka revoke())

Ah, I see. I thought of a hangup as being a physical loss of carrier,
not the method of revoking processes from a TTY. So how come a hangup
can be seen by the pseudo-terminal master? Isn't that something that
should only cause file descriptors to the TTY to become invalid?

-- 
 Ed Schouten <ed@FreeBSD.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]