Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #9835 > unrolled thread

fflush

Started by"Bill Cunningham" <nospam@nspam.invalid>
First post2011-09-01 15:57 -0400
Last post2011-09-09 08:19 +0200
Articles 20 on this page of 27 — 16 participants

Back to article view | Back to comp.lang.c


Contents

  fflush "Bill Cunningham" <nospam@nspam.invalid> - 2011-09-01 15:57 -0400
    Re: fflush Willem <willem@toad.stack.nl> - 2011-09-01 20:09 +0000
    Re: fflush John Gordon <gordon@panix.com> - 2011-09-01 20:23 +0000
      Re: fflush sandeep <nospam@nospam.com> - 2011-09-01 20:49 +0000
        Re: fflush Kenneth Brody <kenbrody@spamcop.net> - 2011-09-02 10:59 -0400
      Re: fflush Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-01 22:06 +0000
        Re: fflush Kenneth Brody <kenbrody@spamcop.net> - 2011-09-02 11:05 -0400
          Re: fflush Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-02 17:04 +0000
    Re: fflush Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-01 14:55 -0600
    Re: fflush pete <pfiland@mindspring.com> - 2011-09-01 19:14 -0400
      Re: fflush Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-01 17:27 -0600
        Re: fflush pete <pfiland@mindspring.com> - 2011-09-01 19:33 -0400
        Re: fflush Seebs <usenet-nospam@seebs.net> - 2011-09-02 01:36 +0000
        Re: fflush Kenneth Brody <kenbrody@spamcop.net> - 2011-09-02 11:08 -0400
          Re: fflush Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-02 09:35 -0600
          Re: fflush Nobody <nobody@nowhere.com> - 2011-09-03 07:24 +0100
        Re: fflush gordonb.47ba6@burditt.org (Gordon Burditt) - 2011-09-02 21:42 -0500
          Re: fflush Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-02 21:01 -0600
    Re: fflush Nobody <nobody@nowhere.com> - 2011-09-02 00:34 +0100
    Re: fflush mathog <dmathog@gmail.com> - 2011-09-02 09:57 -0700
      Re: fflush David Thompson <dave.thompson2@verizon.net> - 2011-09-09 01:28 -0400
    Re: fflush gordonb.o3gsp@burditt.org (Gordon Burditt) - 2011-09-02 21:36 -0500
      Re: fflush Keith Thompson <kst-u@mib.org> - 2011-09-03 12:05 -0700
        Re: fflush Kenneth Brody <kenbrody@spamcop.net> - 2011-09-06 12:51 -0400
          Re: fflush Keith Thompson <kst-u@mib.org> - 2011-09-06 10:51 -0700
    Re: fflush "io_x" <a@b.c.invalid> - 2011-09-03 10:13 +0200
      Re: fflush "io_x" <a@b.c.invalid> - 2011-09-09 08:19 +0200

Page 1 of 2  [1] 2  Next page →


#9835 — fflush

From"Bill Cunningham" <nospam@nspam.invalid>
Date2011-09-01 15:57 -0400
Subjectfflush
Message-ID<4e5fe3b1$0$27973$bbae4d71@news.suddenlink.net>
    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

[toc] | [next] | [standalone]


#9836

FromWillem <willem@toad.stack.nl>
Date2011-09-01 20:09 +0000
Message-ID<slrnj5vpj5.1ug4.willem@toad.stack.nl>
In reply to#9835
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

[toc] | [prev] | [next] | [standalone]


#9837

FromJohn Gordon <gordon@panix.com>
Date2011-09-01 20:23 +0000
Message-ID<j3opkm$649$1@reader1.panix.com>
In reply to#9835
In <4e5fe3b1$0$27973$bbae4d71@news.suddenlink.net> "Bill Cunningham" <nospam@nspam.invalid> writes:

>     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.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]


#9838

Fromsandeep <nospam@nospam.com>
Date2011-09-01 20:49 +0000
Message-ID<j3or4k$b8u$1@speranza.aioe.org>
In reply to#9837
John Gordon writes:
> In <4e5fe3b1$0$27973$bbae4d71@news.suddenlink.net> "Bill Cunningham"
> <nospam@nspam.invalid> writes:
> 
>>     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.

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

[toc] | [prev] | [next] | [standalone]


#9886

FromKenneth Brody <kenbrody@spamcop.net>
Date2011-09-02 10:59 -0400
Message-ID<h42dncVw9Z73cv3TnZ2dnUVZ_ridnZ2d@bestweb.net>
In reply to#9838
On 9/1/2011 4:49 PM, sandeep wrote:
> John Gordon writes:
>> In<4e5fe3b1$0$27973$bbae4d71@news.suddenlink.net>  "Bill Cunningham"
>> <nospam@nspam.invalid>  writes:
>>
>>>      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.
>
> In my experience, fflush() is most typically used on input streams,
> however this is technically an undefined behavior.

My experience is to never use fflush() on input streams, precisely because 
it's UB.  Yes, implementations are allowed to define a behavior, but that 
behavior is certainly not guaranteed to be useable on any other 
implementation.  (In fact, an implementation is free to change its 
definition as far as C itself is concerned.  Angry users, on the other hand...)

As mentioned elsethread, it's useful to force any buffered output to be 
written, while still keeping the file open, and that's probably the only 
reason I use it.  (For example, to make sure that everything written to a 
FILE* being used for IPC, which is required in order to make sure that the 
other end will get everything, and can send a reply.)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]


#9841

FromKleuskes & Moos <kleuske@somewhere.else.net>
Date2011-09-01 22:06 +0000
Message-ID<j3ovle$v37$1@dont-email.me>
In reply to#9837
On Thu, 01 Sep 2011 20:23:50 +0000, John Gordon wrote:

> In <4e5fe3b1$0$27973$bbae4d71@news.suddenlink.net> "Bill Cunningham"
> <nospam@nspam.invalid> writes:
> 
>>     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.

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 )
     ()~*~()   
     (_)-(_)   
-------------------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]


#9888

FromKenneth Brody <kenbrody@spamcop.net>
Date2011-09-02 11:05 -0400
Message-ID<Bq-dneXrT846bf3TnZ2dnUVZ_v2dnZ2d@bestweb.net>
In reply to#9841
On 9/1/2011 6:06 PM, Kleuskes & Moos wrote:
> On Thu, 01 Sep 2011 20:23:50 +0000, John Gordon wrote:
[...]
>> 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.

That line of thought being flawed (IMO) due to the possibly-excessive I/O 
overhead of unbuffered I/O.  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.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]


#9899

FromKleuskes & Moos <kleuske@somewhere.else.net>
Date2011-09-02 17:04 +0000
Message-ID<j3r2ba$9d0$1@dont-email.me>
In reply to#9888
On Fri, 02 Sep 2011 11:05:02 -0400, Kenneth Brody wrote:

> On 9/1/2011 6:06 PM, Kleuskes & Moos wrote:
>> On Thu, 01 Sep 2011 20:23:50 +0000, John Gordon wrote:
> [...]
>>> 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.
> 
> 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 )
     ()~*~()   
     (_)-(_)   
-------------------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]


#9840

FromJoe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date2011-09-01 14:55 -0600
Message-ID<1bippcasow.fsf@snowball.wb.pfeifferfamily.net>
In reply to#9835
"Bill Cunningham" <nospam@nspam.invalid> writes:

>     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.
-- 
"Erwin, have you seen the cat?" -- Mrs. Shroedinger

[toc] | [prev] | [next] | [standalone]


#9843

Frompete <pfiland@mindspring.com>
Date2011-09-01 19:14 -0400
Message-ID<4E6011E1.292A@mindspring.com>
In reply to#9835
Bill Cunningham wrote:
> 
>     Where is the right place to put fflush in a file IO operation?

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.

/* BEGIN new.c */

#include <stdio.h>

int 
main(void)
{
    int integer;
    
    printf("Enter an integer: ");
    fflush(stdout);
    if (scanf("%d", &integer) == 1) {
        printf("\nThe integer is %d\n", integer);
    } else {
        puts("\nTry harder next time!");
    }
    return 0;
}

/* END new.c */


-- 
pete

[toc] | [prev] | [next] | [standalone]


#9847

FromJoe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date2011-09-01 17:27 -0600
Message-ID<1bpqjjrggu.fsf@snowball.wb.pfeifferfamily.net>
In reply to#9843
pete <pfiland@mindspring.com> writes:

> Bill Cunningham wrote:
>> 
>>     Where is the right place to put fflush in a file IO operation?
>
> 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?

[toc] | [prev] | [next] | [standalone]


#9849

Frompete <pfiland@mindspring.com>
Date2011-09-01 19:33 -0400
Message-ID<4E601637.1BA9@mindspring.com>
In reply to#9847
Joe Pfeiffer wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Bill Cunningham wrote:
> >>
> >>     Where is the right place to put fflush in a file IO operation?
> >
> > 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?

Portability isn't a boolean quantity.

That behavior is not guaranteed though.

-- 
pete

[toc] | [prev] | [next] | [standalone]


#9860

FromSeebs <usenet-nospam@seebs.net>
Date2011-09-02 01:36 +0000
Message-ID<slrnj60dc2.mu.usenet-nospam@guild.seebs.net>
In reply to#9847
On 2011-09-01, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]


#9890

FromKenneth Brody <kenbrody@spamcop.net>
Date2011-09-02 11:08 -0400
Message-ID<4E60F16B.8080601@spamcop.net>
In reply to#9847
On 9/1/2011 7:27 PM, Joe Pfeiffer wrote:
> pete<pfiland@mindspring.com>  writes:
>
>> Bill Cunningham wrote:
>>>
>>>      Where is the right place to put fflush in a file IO operation?
>>
>> 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?

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.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]


#9894

FromJoe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date2011-09-02 09:35 -0600
Message-ID<1baaanot36.fsf@snowball.wb.pfeifferfamily.net>
In reply to#9890
Kenneth Brody <kenbrody@spamcop.net> writes:

> On 9/1/2011 7:27 PM, Joe Pfeiffer wrote:
>> pete<pfiland@mindspring.com>  writes:
>>
>>> Bill Cunningham wrote:
>>>>
>>>>      Where is the right place to put fflush in a file IO operation?
>>>
>>> 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?
>
> 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.

[toc] | [prev] | [next] | [standalone]


#9906

FromNobody <nobody@nowhere.com>
Date2011-09-03 07:24 +0100
Message-ID<pan.2011.09.03.06.24.53.709000@nowhere.com>
In reply to#9890
On Fri, 02 Sep 2011 11:08:27 -0400, Kenneth Brody wrote:

> 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.

[toc] | [prev] | [next] | [standalone]


#9903

Fromgordonb.47ba6@burditt.org (Gordon Burditt)
Date2011-09-02 21:42 -0500
Message-ID<w4KdnWI2SZG0CfzTnZ2dnUVZ_uednZ2d@posted.internetamerica>
In reply to#9847
> 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?

Does this work even if the program is invoked as:

	program | tee logfile

?

[toc] | [prev] | [next] | [standalone]


#9905

FromJoe Pfeiffer <pfeiffer@cs.nmsu.edu>
Date2011-09-02 21:01 -0600
Message-ID<1by5y6nxcd.fsf@snowball.wb.pfeifferfamily.net>
In reply to#9903
gordonb.47ba6@burditt.org (Gordon Burditt) writes:

>> 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?
>
> Does this work even if the program is invoked as:
>
> 	program | tee logfile

Not in any real sense.

[toc] | [prev] | [next] | [standalone]


#9851

FromNobody <nobody@nowhere.com>
Date2011-09-02 00:34 +0100
Message-ID<pan.2011.09.01.23.34.30.839000@nowhere.com>
In reply to#9835
On Thu, 01 Sep 2011 15:57:37 -0400, Bill Cunningham wrote:

>     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.

[toc] | [prev] | [next] | [standalone]


#9898

Frommathog <dmathog@gmail.com>
Date2011-09-02 09:57 -0700
Message-ID<j3r1uk$cib$1@dont-email.me>
In reply to#9835
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?

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


[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c


csiph-web