> > And it occurs to me that it might be worth designing a stdio
> > interface which "reads" n bytes by returning a pointer and
> > advancing the read pointer by n, ASSUMING that there are n bytes
> > available.  One possible approach would be to have stdio refuse to
> > refill the buffer until you call back to release the pointer, or
> > you could just take your chances if you're foolish enough to call
> > read again while you're still interested in the previous data.
> 
> It has already been done, IMO.  Take a look at sfio from Vo & Korn @ ATT.

> One application that already recommends the SFIO interface as a speed
> enhancement is INN (unoff-v4 I think).

After Phong Vo's vmalloc presentation at Usenix (where I was very
impressed), I took a look at sfio too.  

I think it's good stuff.  I've been evaluating the possibilities of
using sfio and vmalloc in the NetBSD libc.  While waiting for their
legal department to release the code under a licence that would 
allow us to do so, I've been playing with the code, exchanging
mail and patches with Phong, etc.

	--jtc