X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10201111628.AA15029@clio.rice.edu>
Subject: Re: frlist.c proposed patch
To: eliz AT is DOT elta DOT co DOT il
Date: Fri, 11 Jan 2002 10:28:00 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <2110-Fri11Jan2002094322+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Jan 11, 2002 09:43:23 AM
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

> > This isn't a complete fix for all cases, but it 
> > does make sure we don't set up extra file structures which will be closed
> > that shouldn't.
> 
> What would it take to solve the more general problem?

This particular problem was the byproduct of completely legitmate and
legal usage of calls.  The more general problem has lots of philosophical
questions like "should we protect people from doing things they shouldn't
do".  For example, doing close() on a fileno.

For now at least, I think documenting the close() issue is all that we
should do - lets fix legitimate usage first.

One other way (more complicated) I saw of attacking this problem was 
creating a "FILE structure used" flag.  The startup created structures
would clear this; any use (read/write/open) would set this.  We would
then only close handles we touched.  So, most programs never touch
stdaux or stdprn; since their usage bit was clear we would not close
those handles at exit (fixes problem and saves a few interrupts).

> If you #include <libc/file.h>, fileno will be a macro instead of a
> function.

Excellent idea (I couldn't find the macro).

> > Should we invalidate the handle in the file structure if not open?
> 
> Sorry, I don't understand what does ``invalidate the handle in the
> file structure'' mean.

We create stdin, stdout, stderr, etc assuming the handles 0..4 are 
valid.  If they have been pre-closed then some of those 5 FILE objects
may be invalid.  My fix merely suppresses adding them to the file list 
- but they are still public objects that could be used.

Let's take a pathological case:
 1) parent closes handles 1..4 (including stdout)
 2) child opens a file, writes to it (it is assigned handle 1)
 3) child prints to stdout() - it also goes to his file (uggh) and the
    buffers are all messed up

So, when I do the stdout setup and notice that fileno(stdout) is not
open - I'm saying I should change the file structure to cause failures
instead of stomping on another file.

Or maybe if handles 0..2 are closed we should open them to CON?  Yuk.