From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10108221426.AA18838@clio.rice.edu>
Subject:	Re: Fseek on STDIN problem on Win 2K
To:	eliz AT is DOT elta DOT co DOT il
Date:	Wed, 22 Aug 2001 09:26:18 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com (DJGPP developers)
In-Reply-To:	<8011-Wed22Aug2001092018+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 22, 2001 09:20:18 AM
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

> Does this mean we need to `lseek (fd, SEEK_SET, 0L)' inside _read, to
> avoid breaking following seeks?  Do we need to do that only for handle
> 0, or for any handle?  What about seeks after a write? do they have
> the same problems (with redirected stdout or elsewhere)?

I don't know the answer to any of these questions - we'll have to
write a lot of test programs.  

Here's a thought - I've used lseek/read/write on NT with DJGPP 
somewhat frequently in the last several years without seeing this
problem.  Let's assume for a second this is only seen on handles
opened by NT for us, that have the weird "0" behavior.  If we 
declared these as pipes (completely valid for NT, and a case we
probably need to handle anyway) then no one seeks on STDIN and the
problem goes away.

- Raw text -