Mail Archives: djgpp-workers/2001/09/17/02:21:20
On Sun, 16 Sep 2001, Charles Sandmann wrote:
> 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.
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.
> 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.
> 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?
> 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.
- Raw text -