fflush

[Bill Cunningham]

Where is the right place to put fflush in a file IO operation? Right
before fclose? I never have really used it to flush buffers only to flush
stdout. Is it a good idea to use fflush all the time?

Bill

 

[Willem]

Bill Cunningham wrote:
) Where is the right place to put fflush in a file IO operation? Right
) before fclose? I never have really used it to flush buffers only to flush
) stdout. Is it a good idea to use fflush all the time?

Simple answer: Don't use fflush.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[John Gordon]

Where is the right place to put fflush in a file IO operation? Right
before fclose? I never have really used it to flush buffers only to flush
stdout. Is it a good idea to use fflush all the time?

Closing the file automatically flushes the output, so calling fflush right
before closing the file won't accomplish anything.

Fflush is typically used when you want to ensure that some output gets
written to the file RIGHT NOW but aren't ready to close the file yet.

 

[sandeep]

In <[email protected]> "Bill Cunningham"


Closing the file automatically flushes the output, so calling fflush
right before closing the file won't accomplish anything.

Fflush is typically used when you want to ensure that some output gets
written to the file RIGHT NOW but aren't ready to close the file yet.

In my experience, fflush() is most typically used on input streams,
however this is technically an undefined behavior.

 

[Joe Pfeiffer]

Where is the right place to put fflush in a file IO operation? Right
before fclose? I never have really used it to flush buffers only to flush
stdout. Is it a good idea to use fflush all the time?

You only need to use it if you want to force IO to happen immediately;
there aren't many cases where that's necessary.

One place you *don't* need it is just before an fcloew(), as fclose()
does a flush.

 

[Kleuskes & Moos]

In <[email protected]> "Bill Cunningham"


Closing the file automatically flushes the output, so calling fflush
right before closing the file won't accomplish anything.

Fflush is typically used when you want to ensure that some output gets
written to the file RIGHT NOW but aren't ready to close the file yet.

There is a line of thought that says that under those circumstances you
might want to consider using unbuffered I/O instead.

-------------------------------------------------------------------------------
_______________________________________
/ Yow! Maybe I should have asked for my \
\ Neutron Bomb in PAISLEY -- /
---------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Joe Pfeiffer]

If you want a message to appear on standard output,
which asks the user for input,
then use fflush(stdout) after the message code,
before the input code.

<snip code example>

At least under Linux, the attempt to read the input causes the output to
be flushed (and I verified that this worked for your code example with
the fflush() snipped). Is this not portable behavior?

 

[Nobody]

Where is the right place to put fflush in a file IO operation?

There isn't a "right place". If fflush() is needed at all, the reason
/why/ it's needed dictates /where/ it's needed.

Right before fclose?

No. That's one place where fflush() is never required, as fclose() will
flush the stream.

I never have really used it to flush buffers only to flush

stdout. Is it a good idea to use fflush all the time?

No. Excessive use of fflush() may impose a performance penalty.

 

[Seebs]

At least under Linux, the attempt to read the input causes the output to
be flushed (and I verified that this worked for your code example with
the fflush() snipped). Is this not portable behavior?

Sort of!

It's recommended, but not strictly required, by C99. It seems to be common
on modernish Unixes, but it was pretty uncommon at some point in the past,
which made it become a FAQ that you needed an fflush() to force the prompt
to display.

-s

 

[Joe Pfeiffer]

The only thing I've seen similar to that is, when using a single
read/write stream, the buffer will be flushed when switching from read
to write, or write to read. (And I don't know if even that's
guaranteed by the Standard.) Given that stdin and stdout aren't the
same stream, I fail to see any portability in that behavior.

It does turn out that the buffer flush I'm relying on is non-portable.
If one takes man pages to be in any sense authoritative (a big 'if'
indeed) then the behavior can be relied on in linux, as the setbuf man
page says

The three types of buffering available are unbuffered, block buffered,
and line buffered. When an output stream is unbuffered, information
appears on the destination file or terminal as soon as written; when it
is block buffered many characters are saved up and written as a block;
when it is line buffered characters are saved up until a newline is
output or input is read from any stream attached to a terminal device
(typically stdin).

So all line-buffered streams are flushed when input is read from any
stream attached to a terminal -- under linux, anyway.

 

[mathog]

Where is the right place to put fflush in a file IO operation? Right
before fclose? I never have really used it to flush buffers only to flush
stdout. Is it a good idea to use fflush all the time?

I primarily use fflush() when debugging. When a program is run in Bash
like this:

program >out 2>&1

the only reliable way to get the output to come out in the right order
is to flush after the last of each separate cluster of fprintf(stderr,)
and fprintf(stdout,). Also in a case like this:

valgrind program >out 2>&1

valgrind will send output to stderr, and the program (generally) to
stdout. The order in the output file may be shifted with respect to
each other unless each fprintf(stdout,) is followed by fflush(stdout).

In a normally running program, which only writes to stdout, there is
generally no reason to use it. If a program runs a long time, it is
convenient to fflush once and a while, so that a second program can more
reliably look at the output while the first is still running. That is a
separate problem though, really, which concerns running two programs at
the same time, and passing data between them.

Regards,

David Mathog

 

[Kleuskes & Moos]

That line of thought being flawed (IMO) due to the possibly-excessive
I/O overhead of unbuffered I/O.

In some cases it might and buffering may provide a good solution.

Consider, for example, a simple
fprintf(), which, in implementations I have seen, would cause the
generated output to be written one byte at a time.

That, and other, considerations would prompt one not to choose unbuffered
I/O, but at least you have a reason _why_ you chose to buffer and flush
instead. Much depends on the actual requirements and design parameters.

-------------------------------------------------------------------------------
_________________________________________
/ I'm a nuclear submarine under the polar \
\ ice cap and I need a Kleenex! /
-----------------------------------------
\
\
___
{~._.~}
( Y )
()~*~()
(_)-(_)
-------------------------------------------------------------------------------

 

[Joe Pfeiffer]

Does this work even if the program is invoked as:

program | tee logfile

Not in any real sense.

 

[Nobody]

The only thing I've seen similar to that is, when using a single read/write
stream, the buffer will be flushed when switching from read to write, or
write to read. (And I don't know if even that's guaranteed by the
Standard.)

It isn't; 7.19.5.3p6:

[#6] When a file is opened with update mode ('+' as the
second or third character in the above list of mode argument
values), both input and output may be performed on the
associated stream. However, output shall not be directly
followed by input without an intervening call to the fflush
function or to a file positioning function (fseek, fsetpos,
or rewind), and input shall not be directly followed by
output without an intervening call to a file positioning
function, unless the input operation encounters end-of-file.
Opening (or creating) a text file with update mode may
instead open (or create) a binary stream in some
implementations.

 

[Keith Thompson]

Do not call fflush() on input files or stdin. Forcing the user to
untype input is a safety hazard, especially if the user is not at
the keyboard and is driving or asleep. There's also a remote chance
it could damage the file. fflush() does not mean "take the characters
in the buffer and *discard* them". It means "take the characters in
the buffer and put them in the file."

fflush() on an input file doesn't mean *anything*.

 

[Keith Thompson]

Nit: Some implementations define it to mean "discard anything already read
do to buffered I/O.
Yes.

But, as far as the C language itself is concerned, you are correct that it
doesn't mean anything. In fact, it's a bit more than "doesn't mean
anything", as it's actually defined as being "undefined" (7.19.5.2p2).

Which is exactly equivalent to not being defined at all (4p2).

 

[David Thompson]

I primarily use fflush() when debugging. When a program is run in Bash
like this:

program >out 2>&1

the only reliable way to get the output to come out in the right order
is to flush after the last of each separate cluster of fprintf(stderr,)
and fprintf(stdout,). Also in a case like this:

fprintf or other output operations like fputc/putchar, fwrite, and of
course (!) the wide versions where applicable.

valgrind program >out 2>&1

valgrind will send output to stderr, and the program (generally) to
stdout. The order in the output file may be shifted with respect to
each other unless each fprintf(stdout,) is followed by fflush(stdout).

Alternatively, setvbuf stdout to _IOLBF once at the top of main(),
perhaps conditional on a debugging flag. This avoids missing one
somewhere, especially if you call library code. Also makes the output
nicer (though less exactly sequenced) if any of your output chunks is
not complete lines -- which is usually a bad idea anyway.
It is a little slower if you (frequently) do multi-line chunks; but
IME valgrind is already so much slower you won't notice.

<snip rest>