Missing stdio features.

[Chris Torek]

I wrote:
>>Indeed, there would be a certain symmetry to the whole thing if one
>>could write
>>    reader(f, buf, len) FILE *f; { return (read(fileno(f), buf, len)); }
>>    FILE *f = fopenrf(reader, "r");
>>    fileno(f) = fd;
>>instead of
>>    FILE *f = fdopen(fd, "r");

In article <86900044 at haddock> karl at haddock writes:
>As I mentioned, I think it has to be (void *) in general, thus
>   reader(void *v, char *buf, int len) {
>       return (read(*(int *)v, buf, len));
>   }
>   FILE *f = fopenrf(&fd, reader, "r");

I agree.  Indeed, I had a more voluminous example that used generic
pointers, but I thought that the idea would be hidden by all the
implementation details, so I trimmed it down to the one in >> above.

>You could get away with having the first arg to reader() be "FILE *", but in
>any case "void *_id" needs to replace or supplement the existing "int _file"
>in the FILE structure.

I think the generic pointer is better.  The reading or writing
routine should need no access to the stdio structures, just as
read() and write() need none.

>If there are separate functions fopenrf() and fopenwf(), is there any need
>for the third argument?

I had a reason for including it at the time, but now I cannot recall
it.  Ah well.  There should be some provision for read-and-write modes,
though:

	typedef int (*iofunc)(void *cookie, char *buf, int len);
	FILE *fopenrwf(void *cookie, iofunc r, iofunc w);

(to specify types everywhere).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu