fopen bug in Interactive ix/386 ?

[Larry Philps]

In article <314 at edvcom.UUCP> news at edvcom.UUCP writes:
>
>The following pice of code hangs because it tries to fopen() more than
>_NFILE files. Insteed of returning a NULL pointer after the 18th call
>it returns a 'valid' descriptor and chrashes.
>We are using 1.0.6.
>Any suggestions, maybe someone at ico.ISC.COM reading this group ?

Actually, there is nothing "wrong" here at all - the file descriptor really
is valid.  In System V Rel 3, you can configure the number of allowed open
file descriptors to be anything between 20 and 100.  However in stdio.h you
find

...
#ifndef _NFILE
#define _NFILE	20
...

and in .../lib/libc/port/stdio/data.c you find

...
#include <stdio.h>
...
FILE _iob[_NFILE] = {
...
};

Fopen does not keep track of the number of open stdio streams, so when
finally fd #20 is returned by the kernel, you start clobbering random data in
you program until it crashes.  You can fix the behaviour by configuring your
kernel to only allow 20 open file descriptors, but this may break other
applications that do not use stdio and use lots of fds.

The real solution is to fix fopen to malloc a new iob when it runs out of
statically allocated ones, and make sure that the stdio macros and routines
can access and free these malloced iob's without trouble.  If you don't have
the source, then you are out of luck.

Larry Philps                             HCR Corporation
130 Bloor St. West, 10th floor           Toronto, Ontario.  M5S 1N5
(416) 922-1937                           {utzoo,utcsri,uunet}!hcr!larry