Date: Tue, 21 Aug 2001 20:07:59 +0300 From: "Eli Zaretskii" 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 Precedence: bulk > From: "Andrew Cottrell" > 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.