Mail Archives: djgpp-workers/1999/05/09/07:32:43
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?
- Raw text -