From: pavenis AT lanet DOT lv
To: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Wed, 9 May 2001 18:31:18 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: libstdc++-v3: bug in handling text files for DJGPP
Message-ID: <3AF98CF6.14486.45477F@localhost>
In-reply-to: <3405-Mon07May2001211050+0300-eliz@is.elta.co.il>
References: <3AF6FB4E DOT 3915 DOT 208439A AT localhost> (pavenis AT lanet DOT lv)
X-mailer: Pegasus Mail for Win32 (v3.12c)
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 7 May 2001, at 21:10, 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.

It seems that simple removing this extra seek in basic_filebuf<>::sync()
fixes this bug. Tested with gcc-3.1 20010506 under Linux that my patch
doesn't make any regressions in libstdc++-v3 testsuite.

Binaries can be found at
	http://www.ltn.lv/~pavenis/gcctest.html

Andris