Date: Sun, 26 Aug 2001 10:35:45 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann 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: 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: > 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).