Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Does NEWLINE always flush stdio buffer?
Message-ID: <10487@smoke.BRL.MIL>
Date: 2 Jul 89 08:16:03 GMT
References: <11012@ihlpl.ATT.COM> <12375@bloom-beacon.MIT.EDU> <1989Jul2.040259.3872@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 38

In article <1989Jul2.040259.3872@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>It might be reasonable to default to line buffering for pipes, ...

Line buffering has an additional flaw -- it requires that almost every
character being output be tested against '\n'.

As I recall, the original STDIO implementations did not treat "terminal
devices" (i.e. those responding to tty-oriented ioctls) specially.  Line
buffering appears to have been added later for two main reasons:
	(1) to guarantee that prompts etc. were seen before requesting
	    input from a terminal
	(2) unbuffered output was painfully slow

As has already been noted in this discussion, applications can solve both
problems by using full buffering and issuing an fflush() before an input
request.  That's actually what I prefer, and is essentially how my portable
"Dx" IPC package (part of a large project currently under development)
expects to be used.  My belief is that line buffering is an attempt to
automate a solution to a certain class of application design problems,
without taking into account the possibility you brought up or other,
similar difficulties with automating the determination of when to flush
and when not to flush output buffers.  As seems to always happen, the
attempt to make system software "smart" fails because it takes genuine
intelligence to really solve the problem right, and automated algorithms
following fixed rules cannot properly deal with the entire spectrum of
possibilities.

The proposed ANSI Standard for C suggests (sort of a soft requirement)
what are essentially the current UNIX System V STDIO rules for line-buffered
streams: not only should the output buffer be flushed when a new-line is
encountered or the buffer fills up, but also ALL line-buffered output streams
should be flushed whenever input is requested from an unbuffered stream or
when line-buffered input has to refill its buffer.  The cost of implementing
this can be substantial!  Since it is only a "soft" requirement, I wouldn't
mind at all if implementations claimed that "interactive devices" never
exist, thereby obtaining full buffering by default except for stderr.
Portable applications need to issue explicit fflush()es at the appropriate
times anyway, so we might as well be using full buffering all the time.