Date: Sun, 26 Aug 2001 09:58:12 +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: <10108251652.AA17486@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.1010826095339.3978F-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 Sat, 25 Aug 2001, Charles Sandmann wrote:

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

> > > 4) This problem is masked on 2.04 if lfn=n due to call sequence differences
> > >    (when using fstat).
> > 
> > And just to be sure we are talking about the same issue: by ``this
> > problem'' do you mean the weird behvaior of read and lseek wrt file
> > position?  Or is there anything else?
> 
> 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.

> > Sounds like a good plan to me.  But if an extra seek solves the
> > problem, why not try use it?  We could make it part of this testing as
> > well, to see whether it indeed solves the problems.
> 
> _read() is one of the most heavily used calls in the library.  For all
> DOS 5 systems we will be adding an extra interrupt to get true dos 
> version.

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.

> What about having _get_dev_info be smart about these?

You mean, interpret the zero return value as meaning something?