Message-Id: <3.0.1.32.19971125104044.007e34f0@yacker.xiotech.com>
Date: Tue, 25 Nov 1997 10:40:44 -0600
To: djgpp-workers AT delorie DOT com
From: Randy Maas <randym AT acm DOT org>
Subject: re: proposed fsext changes
Cc: dj AT delorie DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

My apologies for the latest mixup on the copyright line (and other troubles
from cosmetic changes).

Regarding your feedback on the stuff I posted:

I had dup2() call _dup2(), link() call _link(), etc.  to keep the
consistent libc style of where XXX calls _XXX, which in turn calls the
FSEXT and the OS.  Was XXX to _XXX done for special reasons?  Do these
apply to any other functions (eg lseek)?  In other words, which procedures
should be XXX  and  _XXX,  and which should just be XXX?
(I remember some libraries, like "condor", used this feature on unix
libraries to add functionality to the standard API and still use the
lower-level calls).

side question: dup() seems that it should be reflected to an FSEXT through
fcntl(),  should dup2() be reflected to an FSEXT in the same way?

_copy was separated from link() so that all programs and fsext's could
benefit from a _copy routine.  Unfortunately copy() is not a call on any
unixy system I am familiar with.  Maybe it should be called __FSEXT_copy()?


__FSEXT_get_function, __FSEXT_set_function both expect a fixed number of
arguments.   Requiring more parameters would break existing code or
libraries.  I haven't tried it with gcc, but on other compilers pulling
*more* parameters off the stack than provided causes all sorts of havoc.
So I created __FSEXT_get_handler and __FSEXT_set_handler that would work
with the others.  Note: the the proposed fsext's are called with *more*
parameters than v2.01 fsext's expect, this works fine  (eg, main is called
with three parameters, but most programs only use two of these).


__FSEXT_nop:  I wanted/needed this routine for a fsext that works with the
waterloo tcp/ip stack.  An example
chunk of code that uses wattcp:

void Sock_Read(S, Buffer, Size)
	void* S;
        char* Buffer;
	unsigned Size;
{
   unsigned N;
   for (N = 0; !N;)
    {
       kbhit();
       N = sock_fastread(S, Buffer, Size);
       if (!N) tcp_tick(S);
    }
}

The FSEXT would call tcp_tick(S) when a __FSEXT_nop is passed, allowing the
stack some time to keep the tcp connection alive, even if the application
does not want to read or write data.


__FSEXT_close_all 
>What is this for?  Doesn't libc's standard exit() close everything it
>should?

I don't think it does.  exit() calls __stdio_cleanup_hook, which then calls
_fwalk to close all current FILE pointers with file numbers greater than
stderr.   But this only close's fopen'd files.  Did I miss another method
for closing open'd files (that are never used by the fopen/fclose/fread/etc)?

And I believe the pipe / FIFO extension I am working on should be closed at
exit, even when it has replaced stdin, stdout, stderr. 

Randy Maas