Mail Archives: djgpp-workers/2001/09/17/11:00:36
> Sorry, I didn't realize until now how do freopen and _creat connected, and
> how is this related to the problem you discovered in building djdev. I
> now understand that you are talking about the call to freopen inside
> popen.c.
Yes. It was a wild guess and it turned out to be right.
> > 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.
>
> Yes, it's probably a good idea. With FreeDOS, it was shown by someone
> that close/open doesn't work, but dup2 does.
Since I've got a working freopen patch, I'll post/commit it after I
look at it again. Pretty trivial (about 5 lines).
> > 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.
> > 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?
>
> 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).
I'm sure I have to do (open,close) with _creatnew since you can create
readonly files and write to them, but a re-open will fail so you have to
keep the original handle. But I'm not sure we need this on _creat
since a call order swap is almost as good (just the narrow window of
someone nuking the file we created).
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 ?
- Raw text -