Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!zehntel!hplabs!hao!seismo!harvard!wjh12!genrad!mit-eddie!godot!ima!ISM780B!jim From: jim@ISM780B.UUCP Newsgroups: net.unix-wizards Subject: Re: Re: 4.2bsd eof flag in stdio Message-ID: <127@ISM780B.UUCP> Date: Thu, 29-Nov-84 00:52:43 EST Article-I.D.: ISM780B.127 Posted: Thu Nov 29 00:52:43 1984 Date-Received: Sun, 2-Dec-84 04:53:09 EST Lines: 37 Nf-ID: #R:desint:-21200:ISM780B:28500026:000:2018 Nf-From: ISM780B!jim Nov 22 11:17:00 1984 >It is obvious from this, that no distinction is made of EOT chars meaning >anything but the absolute end-of-file on TTY. Quite wrong. As you quoted, EOT terminates an input line, and *if that line is empty*, the return value is zero, and the *zero return value from read* is interpreted as EOF, not receipt of EOT. But that is not really relevant to fread. What is relevant is that the current call to fread stops when it encounters EOF; NOWHERE DOES IT SAY THAT FREAD RETURNS ZERO UPON END-OF-FILE. It doesn't unless an EOF is encountered when fread tries to read its first byte. Nowhere does it say that EOF latches, any more than it does for read. It is the nature of UNIX terminals that you can read past the EOF; that is why fread behaved as it does, totally consistent with the documentation. To quote Bill Shannon, "The bug was that without this change programs using fread on terminals would never report an EOF condition to the user because internally fread would just swallow the EOF and return a short record and the next fread would go on reading past the EOF." But that is exactly what fread should do: return a short record (as documented; read returns 0, as documented) and go on reading past the EOF on the next fread (just as read goes on reading beyond EOF). Only improperly written programs that erroneously assume that fread signals EOF with a zero return value (it doesn't; it isn't documented to) have the "bug". read is different from fread because it is delimited by newline, so that EOT at the beginning of a line always causes a zero return, because the first character of a line must be the first character read (although not necessarily vice versa); this simply isn't true of fread. For routines for which it is true, such as fgets or getc, then the return value can be used to detect EOF. You cannot show that the SysV fread is wrong by quoting the *read* documentation, especially without understanding why the two are different. -- Jim Balter, INTERACTIVE Systems (ima!jim)