From: Martin Stromberg 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: from "Eli Zaretskii" at Feb 12, 2001 09:27:47 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Precedence: bulk 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