Date: Sun, 9 May 1999 14:30:28 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Kbwms AT aol DOT com cc: djgpp-workers AT delorie DOT com Subject: Re: Quirky getch() (fwd) In-Reply-To: <486df3f3.2466c4b3@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 9 May 1999 Kbwms AT aol DOT com wrote: > The thought that every > call to getch() would be preceded by automatic calls to fflush(stdout) > and fflush(stderr) is chilling indeed. Why is it more chilling than what we already do? The current sources (see src/libc/ansi/stdio/filbuf.c in djlsr202) already flush stdout and stderr when a buffer of the stdin stream is empty. Since stdin is line-buffered by default (unless redirected), this means we call fflush for every input line read by stdin. This change was done in v2.02 *precisely* to prevent FAQs such as the one I quoted: people get repeatedly confused by what seems like out- of-order execution. In the case in point, the program called `getch' instead of `getc'. `getch' doesn't go through the buffered stdio functions, and thus doesn't trigger the automatic flushing, but I fail to see how this case is fundamentally different. I think it's very similar. Moreover, while `getc' and its ilk are used to read lots of data, and therefore flushing stdout/stderr for each bufferful might be expensive, nobody in their right mind would call `getch' for anything longer than a few characters (usually, only one), and I have never seen it be called in performance-important loops. So I fail to see the grave effect. And if the above is not enough, fflush is actually a no-op if the buffer is empty, so the only overhead is a function call. Did I miss something?