Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!gatech!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: KSH portability (fd to FILE *)
Message-ID: <11604@mimsy.UUCP>
Date: 21 May 88 03:07:54 GMT
References: <14339@brl-adm.ARPA> <15200005@bucc2>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31
Posted: Fri May 20 23:07:54 1988

In article <15200005@bucc2> brian@bucc2.UUCP writes:
>  Won't
>
>FILE *fdtofp(int fd) { return &_iob[fd] };
>
>  work? Look at stdio.h...

It will not work.  Look at stdio.h, and then look at another stdio.h,
and make sure one is a 4.3BSD stdio.h....

Even in older stdios, _iob[k]._file is not necessarily k: fdopen,
or assignments to fileno(fp) [gack], might make them unequal; and
I am almost certain that a successful open followed immediately
by a successful fopen will make them unequal.

>>What is *really* needed is an array of FILE**, maintained by stdio so
>>that one could do:
>> 	for (i = 0; i < FILEMAX; i++)
>> 		if (FILES[i]) do_something_with(FILES[i]);
>>[Root Boy Jim]

>	for (i = 0; i < _NFILE; i++)
>		if (???) do_something_with(&_iobuf[i]);

Newer <stdio.h>s do not even define _NFILE.  4.3BSD has an array of 20
static _iob's, and dynamically allocates the rest and glues them
together with private data.  The array of static _iob's exists only
because too many programs broke without it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris