Date: Tue, 25 Nov 1997 21:42:39 -0500 (EST) Message-Id: <199711260242.VAA06542@delorie.com> From: DJ Delorie To: randym AT acm DOT org CC: djgpp-workers AT delorie DOT com In-reply-to: <3.0.1.32.19971125104044.007e34f0@yacker.xiotech.com> (message from Randy Maas on Tue, 25 Nov 1997 10:40:44 -0600) Subject: Re: proposed fsext changes Precedence: bulk > 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.