On Thu, 31 Jan 2008 15:21:31 +0000, Walter Roberson wrote:
> In article <fnrta7$aqb$1@online.de>,
> Joachim Schmitz <jojo@schmitz-digital.de> wrote:
>>Walter Roberson wrote:
>>> In article
>>> <695fa4aa-12b5-4128-93cf-64c76594dffb@m34g2000hsb.googlegroups.com>,
>>> Zach <netrek@gmail.com> wrote:
>
>>>> printf("Enter first integer: %d\n",s1); scanf(&s1);
>
>>> After that you do nothing special before you try to read some data.
>>> However, if you want your output to appear before the read starts
>>> happening, you have to call fflush(stdout)
>
>>the '\n' in the printf should have done than.
>
> The '\n' in the printf would only have that effect if the output was
> line-buffered or unbuffered instead of file-buffered. The default for
> streams is file-buffering, except when the system can detect that the
> stream is connected to a "terminal". What a "terminal" is and whether it
> can be reliably detected is not defined by the standard.

It's the other way around. Quoting 7.19.3p7:
"the standard input and standard output streams are fully buffered if and
only if the stream can be determined not to refer to an interactive
device."

If the implementation can't reliably detect interactive devices, it is
not allowed to make the standard input and output streams fully buffered
by default.

> It is safer to
> assume that detection is unreliable and to fflush(stdout) manually.
>
> Historically, there has been interactive usage that was not reliably
> detected, such as in the earlier generations of operations of unix
> pseudo-terminals (ptys).

It *is* safer, I'll admit that, but for different reasons: if you
redirect stdout to a file, and another process reads this file and prints
data to the screen as soon as it is written, that doesn't change the fact
the first process is writing to a provably non-interactive file, and
fully buffered mode is permitted.