fflush(stdout);

[Rajesh S R]

Consider the following code:

#include <stdio.h>
int main( void )
{
printf("Hello");
fflush(stdout);
return 0;
}

fflush(stdout);
Is there a need for the above statement?

If so why do we need it?

Thanks in advance for the reply

[Walter Roberson]

In article <11**********************@q75g2000hsh.googlegroups .com>,
Rajesh S R <SR**********@gmail.comwrote:

>Consider the following code:

>#include <stdio.h>
int main( void )
{
printf("Hello");
fflush(stdout);
return 0;
}

>fflush(stdout);
Is there a need for the above statement?

>If so why do we need it?

There is an automatic fflush() of all writable streams when
the program exits on any hosted environment. (The rules are different
for Freestanding environments.) Therefor in the program above,
the fflush does not add anything.

The program given has a portability problem: the output to stdout
does not finish with a \n. Implementations are permitted to drop
any terminal partial line on text streams. The presence of the
explicit fflush() does not affect this behaviour.

Generally speaking, fflush() has two uses:

1) it releases the current contents of the output buffer to the system
for whatever processing the system has for it. This is useful if
something (or some-one) is waiting for the output. For example if the
program was producing only a few lines of output every tens of minutes,
the user probably would prefer not to wait until the buffer fills up
(8Kb buffers are common) to see what has been happening. And when you
start gettting into interprocess communictions (outside the scope of C
itself), releasing current results for processing can be crucial to
proper operation;

1b) As a subset of the above: releasing an input prompt to the user
just before expecting input can be fairly important to the user;

2) In cases where you are updating a stream (opened with 'r+' or 'rb+'
or 'a+' or 'ab+' modes), flushing written output data before starting
to read from the stream is mandatory. In such an instance,
fflush() itself does not necessarily have to appear: fseek() will
also trigger the necessary flushing.
--
Programming is what happens while you're busy making other plans.

[Default User]

Rajesh S R wrote:

Consider the following code:

#include <stdio.h>
int main( void )
{
printf("Hello");
fflush(stdout);
return 0;
}

fflush(stdout);
Is there a need for the above statement?

In the particular case you show, no. That's because there is no more
more algorithm essentially after the printf(). Exiting the program
flushes all output streams, so you get the effect of the fflush()
implicitly.

Brian

[Rajesh S R]

Thanks for your reply.

That's because there is no more algorithm essentially after the printf().

Can u explain this statement a little more?

[Mike Wahler]

"Rajesh S R" <SR**********@gmail.comwrote in message
news:11**********************@n76g2000hsh.googlegr oups.com...

Thanks for your reply.

>That's because there is no more algorithm essentially after the printf().

Can u explain this statement a little more?

He means that after the 'printf()' the program doesn't
do anything else before it terminates, so there (theoretically)
should be no need to force output buffers to flush. But
keep in mind Walter's cautions about portability.

-Mike

[Keith Thompson]

ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
[...]

The program given has a portability problem: the output to stdout
does not finish with a \n. Implementations are permitted to drop
any terminal partial line on text streams. The presence of the
explicit fflush() does not affect this behaviour.

Theoretically, it's worse than that. All the standard says about this
is (C99 7.19.2p2):

Whether the last line requires a terminating new-line character is
implementation-defined.

It doesn't define what happens if a terminating new-line character
isn't provided. Since the standard doesn't define the behavior, the
behavior is undefined.

Realistically, I'd be very surprised if the result were anything other
than:

(a) You get a text file whose last line just doesn't have a
trailing new-line character; or

(b) The system implicitly adds a new-line character for you; or

(c) The incomplete last line is discarded.

(I'm assuming here that stdout is written to a file.)

But it's possible, as far as the standard is concerned, for the
resulting text file to be ill-formed, and for later attempts to open
it to fail.

And if you're writing to a terminal or emulator, failing to terminate
the last line of output with a new-line can mess up the displayed
output, possibly causing the last line to be overwritten.

The bottom line: don't do that. (Yeah, the "bottom line".)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

"Rajesh S R" <SR**********@gmail.comha scritto nel messaggio
news:11**********************@q75g2000hsh.googlegr oups.com...

Consider the following code:

#include <stdio.h>
int main( void )
{
printf("Hello");
fflush(stdout);
return 0;
}

fflush(stdout);
Is there a need for the above statement?

*Here*, this is a silly thing to do, because of that others have said. The
very least bad thing that could happen (unless the compiler makes a program
which automatically adds a newline at the end) is having the command prompt
on the same line of the output (eg. HelloC:\or
Helloarmy1987@army1987-laptop:~$ or whatever).

Anyway, if you're going to use that in a longer program, this forces the
output to be shown immediately (this is only required when newlines are
printed and stdout is interactive). This is useful, e.g., if you need to
have input on the same line of the prompt. E.g.

fputs("Enter word to search: ", stdout);
fflush(stdout);
fgets(word, WORD_LENGTH+1, stdin);

without the second statement, it might not display the prompt until later.