Message-Id: <3.0.1.32.19980109062850.007c7a90@yacker.xiotech.com>
Date: Fri, 09 Jan 1998 06:28:50 -0600
To: DJ Delorie <dj AT delorie DOT com>
From: Randy Maas <randym AT acm DOT org>
Subject: Re: patch for dup2
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <199801090147.UAA16259@delorie.com>
References: <3 DOT 0 DOT 1 DOT 32 DOT 19980108163555 DOT 007cc9f0 AT yacker DOT xiotech DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

At 08:47 PM 1/8/98 -0500, you wrote:
>> The reason is so that DOS knows not to assign the file descriptor to
>> any subsequent open's or dup's.
>There's a function for that.  __FSEXT_alloc_fd()

I meant something else: the call to DOS needs to be done so that  even
__FSEXT_alloc_fd() does not accidently reuse the descriptor.
__FSEXT_alloc_fd() won't work cause we can't tell it not to use the newfd
descriptor (because __FSEXT_alloc_fd() asks DOS for a unique descriptor and
it does not know that the application is already using certain
descriptors....) 

A simple example:
 let say that I open an incoming fsext file (becoming FD), and I've closed
off STDIN (closing off 0 here is just make the point)
 I want to the incoming FD to work as STDIN so I dup2(FD, 0);
 Then I FD2=open() some other file... FD2 could (and should be, if I
understand DOS) 0!

A more realistic example is something dup2(FD, NewFD) and then a call to
open() also returns NewFD, as a surprise to the user.

I'm not sure I made that as clear as possible.  If you'd like, I can try to
explain it again after I've thought about it some more...  Maybe with a
piece of real code if that helps.
Randy