From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10305131635.AA21803@clio.rice.edu>
Subject:	NT/W2K stdout pre-opened handles/seek
To:	djgpp-workers AT delorie DOT com
Date:	Tue, 13 May 2003 11:35:31 -0500 (CDT)
In-Reply-To:	<10305130425.AA13424@clio.rice.edu> from "Charles Sandmann" at May 12, 2003 11:25:54 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

lseek(1, 0, SEEK_CUR) always returns 0 on NT/W2K on the initial call, even 
when the handle is opened for append to a non zero-length file.  This is
only seen for pre-opened handles; if you run from Bash it works.

if I write to the file first, then lseek(1, 0, SEEK_CUR), then the 
offset returned is the size of the data I wrote, and still incorrect.

if I call lseek(1, 0, SEEK_END) *FIRST*, then the value returned is 
correct on other calls. 

Does anyone see harm in adding something like the following to crt1.c as
a workaround/fix?

if (_os_trueversion == 0x532 && !_USE_LFN) {
  lseek(1, 0, SEEK_END);
  lseek(2, 0, SEEK_END);
}

We maybe should do this even if LFN is available; this code avoids the fstat()
issue but wouldn't fix seeks on WIN2K or XP while forcing the lseek 
even with LFN on would..

It's also possible we should do an lseek(0, 0, SEEK_SET) and remove the
code forcing seeks in filelen.c, which was put there to work around the
similar problem on stdin() noticed by Andrew in August 2001. 

- Raw text -