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
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> 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.