Re: fmemopen

[Bruce Korb <bkorb at veritas dot com>]

On Tuesday 08 March 2005 09:17 pm, Roland McGrath wrote:
> > 1.  I wanted it to work on BSD systems which do not have fopencookie.
> >     They have funopen, which is completely equivalent.
> 
> If you want something portable, then you should not assume you can diddle
> with the stdio buffer directly at all.

We're talking about two different buffers.  I don't want to understand
anything about buffered io's buffers, so I only ever meant to refer
to the chunk of memory where the flushed write data are stored.

> > 2.  the "output" area should be extensible instead of requiring
> >     a presupposed maximum size
> 
> Use open_memstream.

That's closer, except I have to be able to rewind and re-read.
open_memstream's fseek is non-functional.  Also, I didn't even know
about it.  If it isn't documented, I can't find out about it, so,
basically, it doesn't exist.  :(  Also, it seems odd to have two
almost functionally the same interfaces when the only reasons for
doing so are the variations on the disposition and extensibility
of the output buffer.  Stranger still when extensibility can be
inferred from mode flags in the open call.

> > 3.  It ought to be possible to obtain the current buffer address
> >     without requiring that the client allocate stable storage for
> >     the information.  The client need only track the FILE* pointer.
> 
> This is outside the scope of the cookie-style interface, which explicitly
> knows nothing about stdio internals like its buffers.

I am referring to the "bufloc" and "sizeloc" data areas used
by the open_memstream interface.  With an "fioctl" interface,
the fmemopen/open_memstream/whatever-else-you-want functions
can store that information in their own private structures instead
of relying on the caller to ensure that stable, separate memory is
available for each invocation of these functions.  It's cleaner.

> > 4.  The original implementation assumed the buffer had to be a
> >     NUL terminated string.  I assume binary data if the "b" flag
> >     is in the open mode string.
> 
> There is no content constraint on open_memstream's streams.

True, but the lack of fseek make it even less usable for my particular needs.
I still think an "fcookieioctl()" would be very useful. :)

Thanks! - Bruce