From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304260336.AA19080@clio.rice.edu>
Subject: Re: 2.04 status page / 2.04 alpha 1 release schedule
To: djgpp-workers AT delorie DOT com
Date: Fri, 25 Apr 2003 22:36:48 -0500 (CDT)
In-Reply-To: <3EA993C7.31AE27B8@phekda.freeserve.co.uk> from "Richard Dawe" at Apr 25, 2003 09:00:07 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

> But I don't understand how a child can mess up the parent's environment. If a
> child program closes inherited file descriptors, how does that affect the
> parent program? Maybe I'm missing something here. I'm also not sure how the
> parent would notice, unless __setup_file_rec_list is called after the child
> has terminated. (I don't think it is.)

What happens is the program does an unconditional close of the handles 3 and
4 because they are assumed to be associated with stdaux/stdprn during 
exit file rundown, which corrupts the internal buffering.  Maybe it's 
just the child that is corrupted, I can't remember.  Now when we set up 
those file descriptors, if 3 and 4 aren't there we flag them so they don't 
get closed at exit before the real file descriptors they were used with
(which leaves them to be flushed properly).

Or something like that.