ultrix 2.0 _iob storage

[Guy Harris]

>You can't do this with ultrix (2.0) as _iob is only 3 slots long, all
>other struct _iobuf's are allocated dynamically so &_iob[3]....
>just points off into the weeds.
>
>Is the above code deemed to be a reasonable way of doing this?

It's definitely not *portable*.  Whether it's reasonable is another
matter.  If you really truly desperately need to do it, it might be
reasonable.... 

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

It's probably present on systems that have picked up a large chunk of
their standard I/O from 4.3BSD (SunOS 3.2 and later has it).

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

Systems with UNIX-derived standard I/O libraries, and that haven't
picked up the dynamically-growing _iob stuff from 4.3BSD, probably don't
have "_fwalk()" and probably have all the "_iobuf"s in "_iob" as one
array.

Systems with UNIX-derived standard I/O libraries that *have* picked up
the dynamically-growing "_iob" stuff from 4.3BSD, probably have
"_fwalk()" and probably do *not* store *all* their "_iobuf"s in "_iob"
as one array.  However, they probably have more like 20 of them in
"_iob"; as I remember it, one of the 4.3BSD beta versions had only
"stdin", "stdout", and "stderr" static, with all of the others
dynamically allocated, and it was upped to 20 in the final 4.3BSD
version.

>Is this another dec knows best????

Hard to say.  Some of the idea is Berkeley's; I don't know if DEC has
only 3 there because they're still using the beta code or because they
picked up the final code and decided the beta code had the right idea
there.

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

Unfortunately, I don't know of one.  I vaguely remember there were
discussions either in the ANSI C or POSIX committees about having a way
of closing *everything*, but I don't think there was any way to iterate
over all FILEs and call a function on each one.