fmemopen

[Bruce Korb]

In reviewing what I said, it is clear I wasn't clear.  :)
The reason I rewrote fmemopen was severalfold:
1.  I wanted it to work on BSD systems which do not have fopencookie.
    They have funopen, which is completely equivalent.
2.  the "output" area should be extensible instead of requiring
    a presupposed maximum size
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.
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.
5.  I worked harder to more closely emulate the conventions and
    behavior you'd expect from fopen based on the mode flags.
The variable behavior I wanted was to both be able to obtain the
address of the current output memory buffer and to be able to tell
the thing not to deallocate it upon close.  I can do that only by
passing "out of band" data through global variables.  I would prefer
to be able to handle management requests through an ioctl-like
interface.  But, the underlying fopencookie/funopen functionality
would have to support it in some fashion.  *That* is the reason
for my writing.  Thank you :) - Bruce

P.S.  I will happily hand over the rewrite and let you all use it
with "no strings attached", most especially if you give me some
"fcookieioctl()" call.  Attached _is_ the current variation with the
non-working assumption that I could sneak an invalid direction through
the fseek code.

On Monday 07 March 2005 06:37 pm, Bruce Korb wrote:
> 
> Hi,
> 
> I've been futzing with the thing and it would be "really convenient"
> to be able to either get the cookie with some call or other or else
> to be able to have it be able to handle a variation on an IOCTL.
> Neither of these are, alas, possible without doing some ugly games
> with global variables.  Ick.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fmemopen.c
Type: text/x-csrc
Size: 19023 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20050309/ab69ebf0/attachment.bin>