Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/12/84; site desint.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!scgvaxd!wlbr!desint!geoff From: geoff@desint.UUCP (Geoff Kuenning) Newsgroups: net.unix-wizards Subject: Re: 4.2bsd eof flag in stdio Message-ID: <249@desint.UUCP> Date: Tue, 27-Nov-84 20:11:07 EST Article-I.D.: desint.249 Posted: Tue Nov 27 20:11:07 1984 Date-Received: Fri, 30-Nov-84 08:38:01 EST References: <1697@ucf-cs.UUCP> <1796@sun.uucp> <5867@brl-tgr.ARPA> <1246@utah-gr.UUCP> <239@desint.UUCP> <6059@brl-tgr.ARPA> Organization: his home computer, Manhattan Beach, CA Lines: 48 Summary: In article <6059@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn) writes: >Geoff, I think you missed the point: ^D (or whatever) from a terminal >DOES act like EOF if there is nothing between the previous delimiter >and this one, since read() will return a count of 0 on that record. >But I have made good use of the more general behavior of ^D in forcing >non-newline terminated input to the reading process. No, I didn't miss the point. I happen to think that the stdio package should not embed features of UN*X into its assumptions about operating systems. There are lots more operating systems with "hard" EOF's than with soft ones. If you want to make use of the general behavior of ^D, write your program to either use clearerr() or use UNIX I/O. >The only reason repeated reading of an ordinary (disk) file keeps >returning 0 bytes (NOT "EOF"; there is no such thing in UNIX) is >that the file size is static. If the file is being appended to by >some other process, then continued reading should return data AFTER >the original "end of file". The same applies to magtape and terminals. >This is not only reasonable, it is quite useful. As to UNIX having EOF, try looking in read(2). In any case stdio is not UNIX, and grepping stdio.h for EOF will succeed. The features you talk to about (simultaneous read and write, for example) are not available on all OS's. >I much prefer the thoughtful design of UNIX over the attempts to make >it look "safe and ordinary". Good, then use read(2) and write(2). Stdio is explicitly a compatibility package. As such, it _s_h_o_u_l_d be safe and ordinary. >Whatever program you had that required two successive 0-length reads >("EOF" indication, by convention) to detect end of input was simply >WRONG. (Some old-time Pascal programmers may recognize the problem.) >Instead of trying to change UNIX by reducing its generality, why not >fix the erroneous program. There is no excuse for such sloppiness. I can do without the snottiness, Doug. I mentioned in my original posting that I had already fixed the bug. My point was that an inconsistency in the way stdio (_n_o_t UNIX) is implemented caused the program to behave strangely only when reading from a terminal. It is unfortunate that this bug stayed in the system for so long that some people mistook it for a feature. But that doesn't mean we shouldn't fix it. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff