Will reading from stdin() flush output to stdout()?

[Fernando Arbeiza]

Hi:

I need some clarification about a code like this:

printf("%s", "a string with NO trailing newline");
scanf("%d", &i);

Regarding if a fflush() of the standard output is needed or not. I think
the relevant portions of the standard are:

[7.19.3.3] When a stream is unbuffered, characters are intended to
appear from the source or at the destination as soon as possible. [...]
When a stream is line buffered, characters are intended to be
transmitted to or from the host environment as a block when a new-line
character is encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer is filled,
when input is 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. Support for these characteristics
is implementation-defined, and may be affected via the setbuf and
setvbuf functions.

[7.19.3.7] [...] As initially opened, the standard error stream is not
fully buffered; 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.
We have been discussing about it, and there are two opinions:

- The fflush(stdout) after printf() is not necessary, since the
standard guarantees that the string is transmitted to the
environment when the input is requested.

- The fflush(stdout) after printf() is desirable, since the
implicit fflush() is not guaranteed when input is requested. It is
not guaranteed because the standard specify that "support for
these characteristics is implementation-defined".

Could you, please, tell me which (if any) is the correct reasoning?

Perhaps it is a matter of language. English is not my mother tongue, so
I may have misinterpreted the standard.

Thanks in advance,
--
Fernando Arbeiza <URL: mailto:ar****** @ono.com>
Crea tu propio Linux: <URL: http://www.escomposlin ux.org/lfs-es>

[Eric Sosman]

Fernando Arbeiza wrote:

Hi:

I need some clarification about a code like this:

printf("%s", "a string with NO trailing newline");
scanf("%d", &i);

Regarding if a fflush() of the standard output is needed or not. I think
the relevant portions of the standard are:

[7.19.3.3] When a stream is unbuffered, characters are intended to
appear from the source or at the destination as soon as possible. [...]
When a stream is line buffered, characters are intended to be
transmitted to or from the host environment as a block when a new-line
character is encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer is filled,
when input is 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. Support for these characteristics
is implementation-defined, and may be affected via the setbuf and
setvbuf functions.

[7.19.3.7] [...] As initially opened, the standard error stream is not
fully buffered; 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.
We have been discussing about it, and there are two opinions:

- The fflush(stdout) after printf() is not necessary, since the
standard guarantees that the string is transmitted to the
environment when the input is requested.
No; the transmission is "intended" only if the input is from
(1) an unbuffered stream or (2) a line buffered stream with a
special characteristic.

Concerning (1), you know that stdin is not fully buffered if
it communicates with an interactive device. But you don't know
whether it is unbuffered or line buffered -- so you don't know
whether the "unbuffered stream" precondition is true or false.

As for (2), the special characteristic is that input operations
from the stream require the host to transmit some characters -- a
"go ahead" sequence or something of the sort. Again, you have no
way of knowing whether this is the case, so you cannot tell whether
the precondition is true. (Not portably, at any rate.)
- The fflush(stdout) after printf() is desirable, since the
implicit fflush() is not guaranteed when input is requested. It is
not guaranteed because the standard specify that "support for
these characteristics is implementation-defined".

.... and that is yet another reason you cannot rely on the automatic
fflush(stdout). Also, read section 5.1.2.3 paragraph 6:

What constitutes an interactive device is
implementation-defined.

.... which means that even if your stdin stream reads from a joystick
or a data glove, the stream could be fully buffered anyhow if the
implementation doesn't consider such devices "interactiv e."

Call fflush() explicitly when you need the output to appear
"now." Of course, even fflush() cannot guarantee that the
output will appear "soon." For example, consider a stdout stream
that transmits across a satellite link with a significant delay.

--
Er*********@sun .com

[CBFalconer]

Fernando Arbeiza wrote:

.... snip ...
- The fflush(stdout) after printf() is desirable, since the
implicit fflush() is not guaranteed when input is requested.
It is not guaranteed because the standard specify that
"support for these characteristics is implementation-defined".

Could you, please, tell me which (if any) is the correct reasoning?

The one above, which I didn't snip.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Fernando Arbeiza]

On Wed, 04 Feb 2004 18:28:08 -0500, Eric Sosman <Er*********@su n.com> wrote:

Fernando Arbeiza wrote:

- The fflush(stdout) after printf() is desirable, since the
implicit fflush() is not guaranteed when input is requested. It is
not guaranteed because the standard specify that "support for
these characteristics is implementation-defined".

... and that is yet another reason you cannot rely on the automatic
fflush(stdout). Also, read section 5.1.2.3 paragraph 6:

What constitutes an interactive device is
implementation-defined.

... which means that even if your stdin stream reads from a joystick
or a data glove, the stream could be fully buffered anyhow if the
implementation doesn't consider such devices "interactiv e."

I realized that but I took for granted that most implementations would
consider the console an interactive device (I know I should not have
done it; please, don't be cruel ;-).

Thank you (and Mr. Falconer) for your replys.

Regards,
--
Fernando Arbeiza <URL: mailto:ar****** @ono.com>
Crea tu propio Linux: <URL: http://www.escomposlin ux.org/lfs-es>