Date: Mon, 17 Sep 2001 18:20:58 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <2561-Mon17Sep2001182058+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
In-reply-to: <10109171455.AA03227@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: freopen/_creat(w2k) interaction [was: Re: Build problems]
References:  <10109171455 DOT AA03227 AT clio DOT rice DOT edu>
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: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Mon, 17 Sep 2001 09:55:38 -0500 (CDT)
> 
> > > I think that assuming handles return in previous slot is a bad assumption;
> > > this could be causing problems with programs that close stdaux and stdprn
> > > for example (they would get allocated first).
> > 
> > So?  What's wrong with that?
> 
> Scenario (may not be real):
> I close handles 3 & 4 (stdaux,stdprn).  I freopen a file structure that
> was on handle 5 - it will now be on handle 3.  If someone expected a
> same handle (saved fileno or something) would not work.

Getting 3 instead of 5 for the new handle is not different from
getting 6.

> > I'd try the dup2 inside _creat way first.  That's the most general 
> > solution, so if it works, I think we should take it.
> 
> Actually I've patched both in testing (freopen only does it's thing if
> the handle changes).  But the _creat adds yet two more interrupts to
> already ugly code. (open, close, dup, close) vs just (close,open) or
> (open,close - with no guarantee of handle order).

Isn't this the same overhead as in the fix for freopen?

> But do we need to fix _creat at all, since fixing the bug in freopen is
> more general, lower overhead?  Are there other broken pieces of code that
> assume the handle will stay put? (that work with open directly?)
> If you can remember the example from freedos ?

The example where the FreeDOS problem was reported had to do with
redirection.  Normally, you redirect with the dup/open/dup2/close
series.  In that case, some code did dup/close/open instead, and
expected to get the same handle from open as the one closed by the
preceding close.

I don't remember what code was that, but it was from djlsr IIRC.  I
will try to search mail archives on DJ's server.