Date: Sun, 19 Aug 2001 18:22:03 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
Message-Id: <2950-Sun19Aug2001182202+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: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu
In-reply-to: <001301c128b2$21beb2c0$0a02a8c0@acceleron> (acottrel@ihug.com.au)
Subject: Re: Fseek on STDIN problem on Win 2K
References:  <001301c128b2$21beb2c0$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" <acottrel AT ihug DOT com DOT au>
> Date: Sun, 19 Aug 2001 23:23:21 +1000
> 
> I am just about to go to bed and thought I should send this now and work on
> it tomorrow night. It appears that when I open STDIN as a file and set the
> file position to zero it really goes to the third character in the input
> stream. The input stream is a file that I pipe in usign the "<". I have
> included a sample program below that shows the problem. If the test file is
> "1234567890ABCDEF" then the test program reads the "34567" characters on Win
> 2K, but on Win 98 with the same EXE it reads the "12345" characters.
> 
> The example below is based on some code in pch.c arround line 120 from the
> Patch source code.
> 
> The test file is called test and the command line that I execute is:
>     seek <test

It would help if you show what the program prints on Windows 98 and
W2K when you run it.

Did you try this on several files, and did you always see the same
position of the stream, that is the 3rd byte?

Also, what happens with other values passed to fseek?

Just looking at the code of fseek and ftell, I'd suspect that they
just return what lseek tells them, but it would be nice to see if this
is really so by stepping into fseek with a debugger.  If this is so,
we should concentrate on lseek.