Date: Wed, 15 Nov 2000 13:50:13 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: djgpp AT delorie DOT com
Subject: Re: possible fflush bug?
In-Reply-To: <3A12736A.CF611454@example.com>
Message-ID: <Pine.SUN.3.91.1001115134524.23547N-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 15 Nov 2000, Nobody wrote:

> I think I found a bug in fflush. I am using gcc2952b, djdev203b, and
> bnu281b. After creating a read/write binary file, writing to it, doing
> an absolute seek backwards, reading, and calling fflush on the FILE*,
> the file position as reported by ftell jumps to the end of the file;

This is not a bug, but an implementation-defined behavior.  Both ANSI C89 
and the new C9x standards say as part of the `fflush' description:

         If  stream  points  to  an  output stream or an update
       stream in which the most recent operation was not input, the
       fflush function causes any unwritten data for that stream to
       be delivered to the host environment to be  written  to  the
       file; otherwise, the behavior is undefined.

In your program, `fflush' is called after a call `fgetc', so you are 
getting different effects in different implementations.

> Workaround:
> fseek(fp, 0, SEEK_CUR); or fseek(fp, ftell(fp), SEEK_SET); before
> fflush(fp);

Why do you need at all to call `fflush'?  Explaining that would be a good 
starting point towards finding a portable solution.