This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: fmemopen
- From: Roland McGrath <roland at redhat dot com>
- To: bkorb at veritas dot com
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 8 Mar 2005 22:05:02 -0800
- Subject: Re: fmemopen
> That's closer, except I have to be able to rewind and re-read.
> open_memstream's fseek is non-functional.
Seeking is supposed to work, though I can believe it's never been tested
properly in the libio implementation of open_memstream. If it's broken,
report the bug.
> 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. :(
It's in the GNU C Library manual right next to fmemopen.
It's hard to want to help you if you don't even read the manual.
> 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.
That's just nonsense.