From: fred AT genesis DOT demon DOT co DOT uk (Lawrence Kirby)
Newsgroups: comp.lang.c,comp.os.msdos.djgpp
Subject: Re: A funny thing happened!
Date: Wed, 20 Aug 97 17:58:41 GMT
Organization: none
Message-ID: <872099921snz@genesis.demon.co.uk>
References: <33EE4447 DOT 24E09407 AT nospam DOT net> <871305859snz AT genesis DOT demon DOT co DOT uk> <33F0D3EA DOT 528A AT cs DOT com> <33F13D7F DOT 423B9280 AT alcyone DOT com> <871577149snz AT genesis DOT demon DOT co DOT uk> <33F9BFCB DOT 4C7F628A AT alcyone DOT com>
Reply-To: fred AT genesis DOT demon DOT co DOT uk
Lines: 31
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

In article <33F9BFCB DOT 4C7F628A AT alcyone DOT com>
           max AT alcyone DOT com "Erik Max Francis" writes:

>Lawrence Kirby wrote:
>
>> 7.9.3 does *not* guarantee that stdout's buffer is flushed before a
>> character is read:
>> 
>> 1. it doesn't guarantee that stdout refers to an interactive device
>> 
>> 2. even if it does the stream can be line buffered and there is no
>>    new-line character being output above.
>
>That's not the way I read it:
>
>    "Furthermore, characters are intended to be transmitted as a block to
>    the host environment when a buffer is filled, when inputi s requested
>    on an unbuffered stream, or when input is requested on a line buffered
>    stream that requires the transmission of characters from the host
>    environment" (ANSI C 7.9.3).

You stop quoting at the critical point. The Standard continues "Support
for these characteristics is implementation-defined" so the standard
provides no guarantee here that code can rely on.

-- 
-----------------------------------------
Lawrence Kirby | fred AT genesis DOT demon DOT co DOT uk
Wilts, England | 70734 DOT 126 AT compuserve DOT com
-----------------------------------------