Xref: utzoo comp.lang.c:40056 comp.unix.aix:5730
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c,comp.unix.aix
Subject: Re: when to fflush ?
Keywords: fflush , fseek, fwrite
Message-ID: <766@taumet.com>
Date: 14 Jun 91 14:01:34 GMT
References: <504@bally.Bally.COM>
Followup-To: comp.lang.c
Distribution: usa
Organization: Taumetric Corporation, San Diego
Lines: 33

siva@bally.Bally.COM (Siva Chelliah) writes:


>   I have a question.  Does seeking to the end of a file causes a flushing
>of the buffer ? In my opinion it should not.

It is an implementation issue, but I don't see why you would expect the
buffer NOT to be flushed in general upon a seek.  Consider the alternative:

When you write to a stdio FILE, the data you write must go to the current
file position.  If you then seek and do another write, that data must
go to the new file position.  If you seek and read, the read might
involve all or part of the buffered data.  This leaves the implementation
with two main choices:

1.  Always flush just before seeking.  This is always correct (satisfies
    all ANSI C requirements) and takes no extra bookkeeping.

2.  Keep track of where each buffered piece of data goes, and when you
    can't stand it any more, write out all the pieces you have saved.
    When you finally do a flush, you have to be careful to seek to each
    saved position and write the piece of buffer in the order in which the
    buffered write calls occurred from user code.  Each read must also be
    inspected to see whether it corresponds to any of the pieces of data
    saved up.  A read could involve several of the pieces, and these pieces
    might have overwritten one another.  When satisfying the read request,
    all this must be taken into account.  In other words, you must duplicate
    the functionality of the file system in your buffering scheme.

Which would YOU rather implement and verify for correctness?
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com