Mail Archives: djgpp-workers/1997/11/25/21:43:07
> 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
This isn't by design; it's for Borland compatibility and POSIX
emulation. The functions that have _xxx equivalents are the ones
where POSIX and MS-DOS differ in their interpretation of the function.
In those cases, and only those cases, the extra level was added. The
xxx functions provide POSIX functionality, while the _xxx provide the
raw DOS functionality.
> 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?
Perhaps. The fsext stuff was added as needed.
> _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()?
There is no _copy functionality in unix. I don't think we need nor
should have such a function in djgpp as a matter of course. In any
case, copy should be emulated through the existing read/write
emulations of fsext, so that copies between different fsext modules
will work. Most programs that need such functionality already include
it, since unix doesn't have any copy function.
> __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).
I don't think fsext is that popular that we need to be that paranoid
about compatibility, like we would with stat or localtime. If the
problem went the other way (libraries calling applications) I'd be
more worried, because the odds of an old call to a new function are
greater. In most cases, the application will be newer (if they
differ), so the extra parameter will be there when needed. Since
djgpp's includes have full prototypes, this will catch any new
compilations.
> __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:
I used waterloo for lynx, and never needed anything special. You do
those calls in select() and read(), both of which are handled through
fsext. You can't expect applications to do things out of the ordinary
when the purpose of fsext is to emulate ordinary unix things.
> __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)?
OK, this I agree with then. However, I'd like this patch to be
separate from all other functionality, so that it can be reviewed and
added independent of other new functionality. It should be called
*after* the FILE* cleanup in exit(), since that might close some fsext
descriptors.
- Raw text -