Date: Tue, 8 May 2001 09:52:38 +0300 (WET) From: Andris Pavenis To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com Subject: Re: libstdc++-v3: bug in handling text files for DJGPP In-Reply-To: <3405-Mon07May2001211050+0300-eliz@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 7 May 2001, Eli Zaretskii wrote: > > From: pavenis AT lanet DOT lv > > Date: Mon, 7 May 2001 19:45:18 +0300 > > > > basic_filebuf::sync() always advances file pointer by number of bytes > > stored in buffer for output (see seekoff at end of this procedure). > > > > It's OK for example for Linux when there is no special format for text > > files. For DOS (and perhaps also Windows) we're getting problems as > > adding CR before LF is done by fwrite() and as result sync() > > incorrectly moves current pointer back. > > DO I understand correctly that libstdc++ uses its own buffering (as > opposed to the buffering code implemented in libc.a for stdio)? > > If so, it should use code similar to what the DJGPP library does for > buffered I/O functions. > Here is source of basic_filebuf::sync() virtual int sync(void) { bool __testput = _M_out_cur && _M_out_beg < _M_out_end; if (__testput) { // Make sure that libio resyncs its idea of the file position // with the external file. _M_file->sync(); // Need to restore current position. This interpreted as // the position of the external byte sequence (_M_file) // plus the offset in the current internal buffer // (_M_out_beg - _M_out_cur) streamoff __cur = _M_file->seekoff(0, ios_base::cur); off_type __off = _M_out_cur - _M_out_beg; _M_really_overflow(); _M_file->seekpos(__cur + __off); } _M_last_overflowed = false; return 0; } _M_file->sync() is simply fflush(_M_file._M_cfile) Andris