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
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 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.