Date:	Sun, 26 Aug 2001 10:56:13 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
Subject:	Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K)
In-Reply-To:	<10108260745.AA16764@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010826105340.3978N-100000@is>
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

On Sun, 26 Aug 2001, Charles Sandmann wrote:

> > > But if the seek to end behavior provides bug immunity, a much simpler fix.
> > 
> > Doesn't seek to current also solve the problem?  If it does, it should be 
> > much cheaper (seek to end could be slow on large files).
> 
> But seek to end is a one time fix (never have to do it again)

Are we sure this is indeed the case?

> while the
> seek to current must be done before each seek (or so we currently believe,
> maybe it only has to be done once ?)

How can we arrange things to be able to take advantage of this one-time 
fix?  Do we maintain flag per handle which says we already did that or 
not?

I'm thinking about getting lseek work reliably, not just lseek's callers.

- Raw text -