Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: /dev/stdin for 4.3?
Message-ID: <5882@brl-smoke.ARPA>
Date: Fri, 22-May-87 19:27:34 EDT
Article-I.D.: brl-smok.5882
Posted: Fri May 22 19:27:34 1987
Date-Received: Tue, 26-May-87 03:11:30 EDT
References: <7359@brl-adm.ARPA> <983@bobkat.UUCP> <5872@brl-smoke.ARPA> <684@bsu-cs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <684@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
-I see a potential problem here.  Programs that won't let you read from
-standard input will frequently attempt to do seeks within the input
-file.  So to anybody planning to implement /dev/stdin, I suggest adding
-a buffering facility that allows seeks to within the buffered area.
-Make the buffer size configurable at boot time if possible or better
-still, let it be configurable for individual users when they log in.
-(Can UNIX devices use non-kernel buffers dynamically?  I have no idea.)
-
-In fact, pipes ought really to be extended to do dynamic buffering.

I have to strongly disagree with this.  If you can't make a data object
that is inherently sequential act completely as a random-access object
(as you in fact can't in general), then there is no point in
implementing half-measures that add complexity and have dubious utility.

Actually, STDIO buffering suffices for a limited amount of this sort of
stuff on sequential objects.  X3J11 guarantees one character of pushback
on a text stream; implementors will in general have to arrange for two
look-aside pockets since scanf() conflicts with ungetc().