Re: fmemopen

[Bruce Korb <bkorb at veritas dot com>]

On Tuesday 08 March 2005 10:05 pm, Roland McGrath wrote:
> > 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.

I was looking at the wrong file.  Whatever I was looking at was
no-oping the seek code and I thought it was the opem_memstream stuff.
Anyway, it _is_ broken:

> #include <stdio.h>
> int
> main (void)
> {
>   char *bp;
>   size_t size;
>   FILE *stream;
> 
>   stream = open_memstream (&bp, &size);
>   fprintf (stream, "hello, ");
>   fflush (stream);
>   rewind (stream);
>   fprintf (stream, "world");
>   fclose (stream);
>   printf ("buf = ``%s'', size = %d\n", bp, size);
> 
>   return 0;
> }
> $ cc -o foo foo.c ; ./foo
> buf = ``world'', size = 5

The correct answer is "7".  Here are the results for:

1) my (modified) version of fmemopen
> $ cc -g -o foo foo.c ; ./foo
> buf = ``world, '', size = 7

2) using fopen to a file
> $ cc -g -o foo foo.c ; ./foo
> buf = ``world, '', size = 7

So, it's a bug.  I haven't tried the glibc "fmemopen" tho.

> > 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 google stuff, but even if I found it, it did not cover my needs.

> > 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.

It's cleaner.   The open_memstream requires the caller to manage the
storage for three values (FILE*, char* and size_t) and the latter two
must not move (ie they may not be part of a memory block that might
be realloc-ed).  And if you have multiple concurrent such opens, then
each must have their own private fields.  It is a clumsy interface.
Adding an "fioctl()" interface would allow this in-memory io stuff to
return the current buffer address from its own internally managed values.
*ALSO* it would allow for other user space i/o functionality to include
various management functions.  The default implementation should
pass the arguments through to the underlying fd.  fopencookie does not
have an underlying fd, so its default would return ENOSYS.  However, I'd
want to register my own "fmem_ioctl()" function that would do things.

Thank you for giving this your consideration.

Regards, Bruce