Missing stdio features.

[karl at haddock]

jpo at cs.nott.ac.uk (Julian Onions) writes:
>All in all, fselect is the right way to go (stdio features tracking
>system calls), ...

Hasn't anyone noticed that at least part of the purpose of stdio is to make
code portable?  Some systems (even some UNIXes) don't have any way to write
a function such as fselect().

>>FILE *fopenfxn(int (*fxn)(), char *mode)
>>       Function-stream I/O.
>Can't say I've ever thought about this one. I'm not sure when you'd
>use it either.

Potentially useful, though kind of slow if it has to pass one character at a
time through the function.  But (ignoring error conditions) the first arg
should be "char (*)(void)" if the second is "r", or "void (*)(char)" if the
second is "w"; this could cause problems with type-checking.  (Best solution
is to drop the second arg and use two functions, I think.)

Actually, the function argument should probably be analogous to read/write
rather than getc/putc.  But there should be one more argument to fopenfxn(),
viz. a (void *) argument to be passed to fxn() to distinguish streams.

>>FILE *fopenstr(char *str, int len, char *mode)
>>      An extension to sprintf() and sscanf().  This returns a stream
>>      which performs I/O to a string (this makes sprintf() and
>>      sscanf() unnecessay, though they are still convenient).
>I like this one, C++ has something like this in its streams stuff,
>and I liked the idea there. Being able to treat incore strings and
>files the same seems a good idea.

I like it too, but maybe it should be called "stropen" (cf. "fdopen").  It's
a good idea to require the len argument even for string reading, so '\0' can
be treated as an ordinary character if desired.

Karl W. Z. Heuer (ima!haddock!karl; karl at haddock.isc.com), The Walking Lint