Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.bugs.4bsd
Subject: Re: read() from tty has fencepost error
Message-ID: <732@haddock.ISC.COM>
Date: Tue, 14-Jul-87 18:49:44 EDT
Article-I.D.: haddock.732
Posted: Tue Jul 14 18:49:44 1987
Date-Received: Thu, 16-Jul-87 01:36:48 EDT
References: <648@haddock.UUCP> <3320@diku.UUCP>
Reply-To: karl@haddock.ISC.COM (Karl Heuer)
Distribution: world
Organization: Interactive Systems, Boston
Lines: 18

In article <3320@diku.UUCP> thorinn@diku.UUCP (Lars Henrik Mathiesen) writes:
>According to the 4.3 tty(4) manual:  "... any number of characters may be
>requested in a read ... without losing information."  But if the next read
>(after the read( , , 5)) returned some further input, you would never know
>that the EOF was there, thus information is lost.

True.  (I don't think that's what they meant by "information", though.)

>But if we want to be able to detect arbitrary EOFs even when it is not
>practical to provide a buffer large enough for any input, the BSD behaviour
>is necessary.  Regrettably you have to use code like this: [complicated code
>that uses an extra variable and observes newlines and full buffers].

But the fact is that existing code -- e.g. the guts of getchar() -- does not
do anything of the sort, and therefore will behave as if a real end-of-file
were signalled.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint