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