Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!rochester!ritcv!mjl From: mjl@ritcv.UUCP (Mike Lutz) Newsgroups: net.unix-wizards Subject: Re: stdio buffering considered harmful Message-ID: <460@ritcv.UUCP> Date: Thu, 4-Aug-83 16:00:06 EDT Article-I.D.: ritcv.460 Posted: Thu Aug 4 16:00:06 1983 Date-Received: Fri, 5-Aug-83 04:28:10 EDT References: sri-arpa.3667 Lines: 25 I disagree with Doug Gwyn's suggestion that programmers should be responsible for fflush()ing "relevant" output before doing input; what is more, I don't think it's a question of sloppiness/neatness. Taken to an extreme, the use of libraries at all is sloppy (printf is the lazy way of getting around number conversions, and the window package is a crutch for those too indolent to keep track of what's on the screen). I don't think Doug meant to be so pedantic as to forbid all library routines, but I also believe the issues in an I/O package's functional design are subtle. If programmers embed flushing decisions in their code, users are denied the option of solving the buffering problem THEIR way. Second, every programmer has a slightly different notion of when to call fflush(), so the behavior of commands in a pipeline will be even more unpredictable than now. (One could invent "standards" for the use of fflush(), but then why not relieve the programmer of an unnecessary burden and implement the standard as part of the library?) Finally, who has the time or patience to go through every program on the system inserting calls to fflush()? All of this is not to suggest that I have the ultimate answer to the buffering problem; I don't (and I have reservations about the proposals that have been made). However, if and when a suitable answer becomes available, I hope it's part and parcel of the standard I/O package. Mike Lutz {allegra,seismo}!rochester!ritcv!mjl