Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: ultrix 2.0 _iob storage
Keywords: ultrix stdio _iob _fwalk()
Message-ID: <8780@smoke.BRL.MIL>
Date: 27 Oct 88 21:44:03 GMT
References: <575@jim.odr.oz>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 40

In article <575@jim.odr.oz> jon@jim.odr.oz (Jon Wells) writes:
>#ifdef BSD
>nfiles = getdtablesize();
>#else
>nfiles = NFILES;
>#endif
>for ( p = &_iob[3]; p < _iob[nfiles]; p++ )
>	fclose(p);
>Is the above code deemed to be a reasonable way of doing this?

No, of course not.  One wonders what the code REALLY needed to do,
since this attempted drastic action would seldom be called for.

>Is _fwalk() standard on other genders of unix???

No _-prefixed identifier other than _exit is standard.

>Does everyone else store all the _iobuf's in _iob as one array?

No.  Many recent implementations dynamically allocate all but the
first three FILE structures.

>Or is there a much better way of closing everything but stdin etc.????

If an implementation conforms to the (proposed) ANSI C standard,
which most won't do for some time to come, then you can use
fflush((FILE*)NULL) to force buffered output to be sent to the
system.  Normally you only worry about this right before a fork,
and since most forks do no stdio before performing an exec, all
they need to do in this regard after the fork is to close the
extra file descriptors (not even trying to worry about stdio
streams).

If a process has any business closing stdio streams, it should
keep track of the handles (FILE *) for each open stream and use
them for this purpose.

Closing the standard streams can be a problem in some cases,
since for example it could remove all access to the controlling
terminal.