Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mimsy!eneevax!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.unix.questions Subject: Re: Stdio flaws? Message-ID: <5904@brl-smoke.ARPA> Date: Thu, 28-May-87 22:19:59 EDT Article-I.D.: brl-smok.5904 Posted: Thu May 28 22:19:59 1987 Date-Received: Sat, 30-May-87 11:33:34 EDT References: <345@phoenix.PRINCETON.EDU> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Distribution: world Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 48 In article <345@phoenix.PRINCETON.EDU> lgy@pupthy.PRINCETON.EDU (Larry Yaffe) writes: > There does not appear to be any clean/portable way to either >(a) flush an input stream, such as stdin, I don't know quite what that would mean. "Flushing" an output buffer does not mean discarding the data in it; it means forcing data buffered in the STDIO library to be sent to the operating system. The analogous effect for an input stream would be to force the operating system to supply the unread STDIO-buffered input data, but it has already done that. Assuming from your example that you meant that you want a way to discard unread data on a stream, note that input data is often at least partially buffered in the operating system (e.g. UNIX kernel), not in user process address space which is where STDIO has to operate. The proposed ANS for C requires that fflush() on an input stream undo the effect of any preceding ungetc() operation on the stream; so far as I can judge, it does not prohibit an implementation from discarding more unread input than that, but it certainly does not require it (since, among other things, in general it cannot be accomplished) and I would be annoyed at any implementor who decided to do so. On most UNIX-like systems, there is a way to flush kernel-buffered input from terminals (e.g. change to RAW mode and back). Some of these also produce undesirable effects on terminal output. Since UNIX usually returns one input line at a time for read()s from a terminal, if you have input through a new-line via STDIO, there would be no additional STDIO-buffered input from a terminal until the next time you attempted input from it. Therefore, forcing the kernel to discard type-ahead at that point would be meaningful and potentially useful. On UNIX System V, the termio ioctl command TCFLSH can be used to flush terminal input and/or output queues (kernel buffers), as you noted. > or (b) truncate an existing, open file. There isn't a simple way to implement that. On older UNIX systems, truncating a file had to be accomplished by copying the file into a temporary file, recopying the temporary file up to the truncation point onto the original after re-creat()ing it (which truncates it to 0 length). Needless to say, this is a non-atomic operation. 4.nBSD supports an ftruncate() system call, as you remarked, but I don't know of a UNIX System V equivalent. It would certainly be useful, since Fortran-77 is required to support file truncation. So the reason for the "serious flaws" is simply that they cannot be implemented reasonably in the STDIO library on all systems (not even on all UNIX-like systems). I consider it a "serious flaw" that I don't have a universal interface to multiple processes and pipes, but so what?