Date:	Tue, 21 Aug 2001 20:07:59 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	acottrel AT ihug DOT com DOT au
Message-Id:	<8011-Tue21Aug2001200758+0300-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
In-reply-to:	<001101c12a42$7776d850$0a02a8c0@acceleron> (acottrel@ihug.com.au)
Subject:	Re: Fseek on STDIN problem on Win 2K
References:	<10108200508 DOT AA15103 AT clio DOT rice DOT edu> <2950-Mon20Aug2001093159+0300-eliz AT is DOT elta DOT co DOT il> <002501c12980$4c67fa80$0a02a8c0 AT acceleron> <2110-Mon20Aug2001172450+0300-eliz AT is DOT elta DOT co DOT il> <001101c12a42$7776d850$0a02a8c0 AT acceleron>
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

> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Tue, 21 Aug 2001 23:08:31 +1000
>
> I found that the problem appears to be in the 3F00 call. I have included a
> sample app below that can be used to debug and test any changes.
> If I comment out the 3F00 call and instead use _read() these also cause the
> problem to occur, this is expected as _read() also calls 3F00.

But your annotations in the source seem to indicate that the first two
calls to seekerprint fail, while the other 3 succeed.  Do you have any
potential explanation for this?  The calls seem identical, or am I
missing something obvious?

> The output from the sample app I am using (with allow more conditional
> printf's and #if 0... for debugging) is:
> seek.c 178 4200, flags = 0x02 pos = 0x0000:0000   Char at offset [0] = (3)
> seek.c 178 4200, flags = 0x02 pos = 0x0000:0001   Char at offset [1] = (4)
> seek.c 178 4200, flags = 0x02 pos = 0x0000:0000   Char at offset [0] = (1)
> seek.c 178 4200, flags = 0x02 pos = 0x0000:0001   Char at offset [1] = (2)
> seek.c 178 4200, flags = 0x02 pos = 0x0000:0002   Char at offset [2] = (3)

Thanks for the footwork.  However, it is hard to track what yuo
describe, because the above output is inconsistent with the program's
source you posted.  Could you please post a session script which shows
output from the source of the test program you posted, including
output from ac_get_magic?

> Taking a wild guess could this be something to do with the STDIN being
> openned as a LFN and the 3F00 requiring a SFN type handle?

So you are saying that any lseek after reading from handle 0 isn't
working?  That is, you can't seek a file if it was redirected into the
standard input?

If so, either they treat handle 0 specially, or the reason is deeper.
How about if you open a file with LFN call--does lseek after read work
then?

> (I have no idea how the STDIN handle is setup.)

It isn't set up by our library, itr is simply preconnected by the
shell whcih invoked the DJGPP program.  That is, when the DJGPP
program starts, its handle 0 is already connected to the file, instead
of being connected to the CON device.

- Raw text -