[Courses] Re: [C] A clarification on fflush(stderr)

Anand R anand.r at cybertech.co.in
Thu Aug 8 18:43:31 EST 2002

Thanks Laura. Which means I can safely assume that flushing stderr is a
programming best practice. 

-----Original Message-----
From: Laura Bowser [mailto:lbowser at andrew.cmu.edu]
Sent: Thursday, August 08, 2002 6:41 PM
To: Anand R
Subject: Re: [Courses] Re: [C] A clarification on fflush(stderr)

Another *really* useful use for fflush is when you're trying to debug a 
program which segfaults.

You have a lot of printf statements to try to help you figure out where your

code segfaults, but nothing interesting prints.

What happens is:
your debug message goes to the stdout/err buffer
it crashes
your debug message is never printed leading you to look in the wrong place
your error.

if you fflush your debug statements as soon as they're made, you can
the location/cause of the segfault much easier.


>Hey thanks so much Malcolm and Laurel. This is something really good and
>something that we can discuss. I read something in a Programmers manual for
>I/O. And this is what I found:
>>>>>>>>>>>>>>>TEXT BEGINS HERE>>>>>>>>>>>>>>>>>>>>>>
>    Input/Output
>The standard I/O library provided to analysis routines does not
>automatically flush and close streams when the instrumented program
>terminates, so the analysis code must flush or close them explicitly when
>all output has been completed. Also, the stdout and stderr streams that are
>provided to analysis routines will be closed when the application calls
>exit(), so analysis code may need to duplicate one or both of these streams
>if they need to be used after application exit (for example, in a
>ProgramAfter or ObjAfter analysis routine -- see AddCallProto(5)).
>For output to stderr (or a duplicate of stderr) to appear immediately,
>analysis code should call setbuf(stream,NULL) to make the stream unbuffered
>or call fflush after each set of fprintf calls. Similarly, analysis
>using C++ streams can call cerr.flush().
>>>>>>>>>>>>>>>>>>>TEXT ENDS HERE>>>>>>>>>>>>>>>>>>>
>And this is what I read in Turbo C help
>>>>>>>>>>>>>>>TEXT BEGINS HERE>>>>>>>>>>>>>>>>>>>>>>
>fflush                           <STDIO.H>
> Flushes a stream
> Declaration:  int fflush(FILE *stream);
> Remarks:
>If the given stream has buffered output, fflush writes the output for
>to the associated file.
>The stream remains open after fflush has executed. fflush has no effect on
>an unbuffered stream.
> Return Value
>  þ On success, returns 0
>  þ On error, returns EOF
>>>>>>>>>>>>>>>>>>>TEXT ENDS HERE>>>>>>>>>>>>>>>>>>>
>Others: What is your opinion about flushing stderr?? I have seen Stevens do
>it. I have seen Hobbit do it. And many more..Could there be something more
>to this, than just habit !!
>Mary: Please advise. How do we resolve this dilemma??
>-----Original Message-----
From: Laurel Fan [mailto:laurel at sdf.lonestar.org]
>Sent: Thursday, August 08, 2002 12:57 AM
>To: 'courses at linuxchix.org'
>Subject: Re: [Courses] Re: [C] A clarification on fflush(stderr)
>On Wed, Aug 07, 2002 at 11:52:15AM -0400, Malcolm-Rannirl wrote:
>> On Wednesday 07 August 2002 02:31 am, Anand R wrote:
>> > 	Just a small doubt. I have seen many flushing stderr in their code.
>> > Why is it necessary to flush stderr?? A small code example below:
>> One I can actually answer. :)
>> When you write to stderr (or any other file), the output is buffered by
>> OS, because it's not very efficient to write everything to disk
>> Unfortunately, if your program (or the OS, as I've had happen with
>> crashes then those buffers die with it and anything in them is lost.
>Actually, I believe every output stream/file _except_ for stderr is
>buffered by default (in C using stdio).  Therefore stderr is the only
>stream that you _don't_ need to flush, which is one reason why stderr
>is a good place to put errors.  If you see fflush(stderr), it's
>probably from habit (and it won't do any harm).  (Of course, you can
>make stderr buffered, or make anything else unbuffered, see manpage
>for setbuf).

Public Key available at 

More information about the Courses mailing list