From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109170402.AA14445@clio.rice.edu>
Subject: freopen/_creat(w2k) interaction [was: Re: Build problems]
To: eliz AT is DOT elta DOT co DOT il
Date: Sun, 16 Sep 2001 23:02:52 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com (DJGPP developers)
In-Reply-To: <2110-Sun16Sep2001213002+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 16, 2001 09:30:03 PM
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

> > Take a quick look at freopen - it looks like to me that we don't try and
> > force the handle number to be the same, so this would break ?
> 
> It happens automatically: if you first close a handle and immediately
> open a file, you get the same handle.  Unix guarantees that, DOS
> doesn't, but all versions of DOS/Windows I've seen, with the single
> exception of FreeDOS, work like that.  (IMHO, that's a bug in
> FreeDOS.)

However, by re-opening the file while open, then closing the original 
handle, we don't guarantee this behavior.

> > (I'm don't ever use freopen so maybe I'm wrong.  If it is fragile with
> > respect to handle number, should freopen at least check this or dup2
> > itself?)
> 
> It probably should play safe and dup2 if required.  But it is much
> less important for freopen, since (1) freopen returns a FILE object,
> so the probability of someone looking at the handle is small, and
> (2) freopen is an obscure and seldom-used function, so we might have
> gobs of bugs there that no one has ever seen ;-)

But when freopen'ing stdin/stdout/stderr, I'll bet there are unixy codes
that make assumptions ... And I'll bet if the handle isn't 0,1,2 the
child doesn't inherit it properly.

If I modify _creat to dup2() the handles so that it uses the first one - 
I don't see the problems.  However, if I modify freopen to fileno the old 
handle, and then do the dup2() there, this also works without needing to 
change _creat.

This tells me that the strange _creat behavior turfed up an old bug in
freopen.  The note above about freedos makes me think we ought to fix
freopen anyway.

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).  I would think that fixing
freopen is the correct fix (bonus, you only make additional interrupt calls
if the handle moves, where most users of open/_creat couldn't care less). 
But I fear if freopen makes this assumption, maybe other code does also.
If this is the case, we probably should fix _creat/_creatnew also (in 
addition to freopen if we want to be really paranoid).

Is fixing freopen enough?  Try it and see?  Swap the open/close to close/open
on the _creat? add dup2() and close() calls all over the place?