From:	Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
Message-Id:	<200102120829.JAA14741@lws256.lu.erisoft.se>
Subject:	Re: Bug000323
To:	djgpp-workers AT delorie DOT com
Date:	Mon, 12 Feb 2001 09:29:31 +0100 (MET)
In-Reply-To:	<Pine.SUN.3.91.1010212092729.12969E@is> from "Eli Zaretskii" at Feb 12, 2001 09:27:47 AM
X-Mailer:	ELM [version 2.5 PL3]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Eli said:
> On Sun, 11 Feb 2001, Martin Str|mberg wrote:
> 
> > > Ah, I see why.  The test program prints a very short string and then
> > > closes the file.  So the entire text is buffered inside the FILE
> > > object when fclose is called, and it is up to fclose to flush it.
> > > fclose calls fflush, but fflush doesn't go through _fslbuf, it calls
> > > _write directly.  (I don't remember why, but it probably has a good
> > > reason.)
> > > 
> > > Solution: add llseek to fflush, and you solved two problems: no need
> > > for llseek in _doprnt, and a bug with writing the last portion of the
> > > data from fflush is also squashed ;-)
> > 
> > Ok. I found the bug. Now it works without changing fflush(). Should
> > that part still be added you think?
> 
> Kinda hard to tell without knowing what bug did you find and how did
> you correct it.  For example, does the corrected code make fflush
> write at the end of the file?

Sorry... The problem was in fopen(). The code had become something
like this (from memory):
if( append )
{
	f->_flag |= APPEND;
}

if( write )
{
	f->_flag = WRITE;
}
else
{
	f->_flag = READ;
}

So without any changes to fflush() it works fine now. 

The question is: did you find another real bug in fflush()?


Right,

						MartinS

- Raw text -