From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108260713.AA13892@clio.rice.edu>
Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K)
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 26 Aug 2001 02:13:37 -0500 (CDT)
Cc: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1010826095339.3978F-100000@is> from "Eli Zaretskii" at Aug 26, 2001 09:58:12 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > If you call get_magic under 2.03 you can see the problem, but if you
> > call fstat() - which calls get_magic, you don't.  So some sequence of
> > additional calls on the handle under 2.03 makes the problem go away.
> 
> Didn't Andrew say that he sees the problem even with v2.03?

Yes, calling get_magic on stdin without fstat() first.  Not a normal 
activity.  If you don't redirect, it waits for you to type the magic
number in on the console.

> > The problem specifically is Andrew's original test problem using fstat()
> > on stdin and that causing subsequent calls to read to have missed the
> > first 2 characters in the file.
> 
> I think there are several problems that contribute to that.  Perhaps we 
> should fcator them and decide in what order to handle/fix them.

It looks like seeks work on pipes, so I'm now in the mood to fix seeking
on handle 0.  If you are interested in implmentation of pipe techical
details, I'll tell you some other interesting things NT/2K do :-)

The simple fix (see other) is the V2.03 seek to find file length behavior.

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

But if the seek to end behavior provides bug immunity, a much simpler fix.

> > What about having _get_dev_info be smart about these?
> 
> You mean, interpret the zero return value as meaning something?

That was a thought, yes.  But since seeks work on pipes, we might as well
take advantage of it.