Date:	Sun, 26 Aug 2001 10:35:45 +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:	<10108260713.AA13892@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010826103321.3978L-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:

> If you are interested in implmentation of pipe techical
> details, I'll tell you some other interesting things NT/2K do :-)

Yes, please.

> > This is a misunderstanding, I think: I was suggesting an extra seek 
> > inside lseek, not inside _read.  I understand that if you call _read 
> > without seeking in between, everything's dandy.
> 
> This is what I was thinking but is different than Andrew's current 
> patches.  But we ought to move the 5 different calls to seek to a single
> core routine (say _seek?) instead of patching 5 files 
> (llseek, filelen, is_exec, lfilelen, lseek).

I don't see any problem to make them all call a single function.  But 
let's first find the best solution for that single function.

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

- Raw text -