Mail Archives: djgpp-workers/2001/09/17/11:26:03
> 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.
- Raw text -