Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!ncar!noao!asuvax!mcdphx!mcdphx.UUCP!ross
From: ross@mcdphx.UUCP (Ross Inglis)
Newsgroups: comp.unix.questions
Subject: Re: fopen bug in Interactive ix/386 ?
Keywords: unix,SYSV,ix/386
Message-ID: <10873@mcdphx.phx.mcd.mot.com>
Date: 11 May 89 17:49:32 GMT
References: <314@edvcom.UUCP> <579@hcr.UUCP>
Sender: listen@mcdphx.phx.mcd.mot.com
Reply-To: ross@mcdphx.UUCP (Ross Inglis)
Distribution: na
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 27

>In article <314@edvcom.UUCP> news@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.

In article <579@hcr.UUCP> larry@zeus.UUCP (Larry Philps) writes:
>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

Sorry, I think there's something wrong...
I was recently looking at the same problem on MCD's version of SysV. 
I found a bad loop in the stdio routine findiop().  The loop would
incorrectly return one more _iob than was legal, because it assumed
that a pointer _lastbuf was pointing to the last useable buffer when, in
fact, it pointed PAST the last buffer.  We recoded the five-line loop which
fixed the hang-up problem and allowed stdio to happily return a NULL
pointer after 20 (or whatever) files even though the kernel had NOFILES set
to 100.

BTW The hang appeared to be due to the fact that the sprintf() routine
reserves that last + one buffer for its personal use (and expects it to
remain unused).

Ross.