🚀 go-pugleaf

Hello:

Under SunOS 4.1.3, with the stock "c" compiler, there is
an in-advertent limitation on the number of open file-descriptors that
can be accessed through stream-style I/O (fopen, fclose and friends).
They built their I/O libraries with "_file" defined as "char" rather
than "unsigned char".  So, instead of having the use of 256; you get 127.

Does anyone know if compiling with GCC, and using any associated 
gnu/gcc I/O facilities will provide a work-around for the "127-desriptor"
limit?

thanks very much,
Bob
enger@reston.ans.net
+1.703.758.7722

ps
To see the limit, simply write a program to "fopen" 240-or-so files,
then write a little something into them, and try to fclose them.
If you check for the return value on the fclose, you'll find out that
the fclose's above descriptor 127 fail.  Also, if you look into the
files, you'll find that the files accessed with descriptors above 127
are empty.

pps
The attached segment from the "/usr/include/stdio.h" file in SunOS 4.1.3
shows the definition of the "iobuf", and within it the "non-unsigned"
definition for "_file".

/*      @(#)stdio.h 1.16 89/12/29 SMI; from UCB 1.4 06/30/83    */
 
# ifndef FILE
#define BUFSIZ  1024
#define _SBFSIZ 8
extern  struct  _iobuf {
        int     _cnt;
        unsigned char *_ptr;
        unsigned char *_base;
        int     _bufsiz;
        short   _flag;
        char    _file;          /* should be short */
} _iob[];