Re: work in progress: [PATCH 0/2+] open_memstream

[Jim Meyering]

Eric Blake wrote:
> The libvirt project would be very interested in using open_memstream,

And many other people, I'm sure, once they learn that
it exists and can be used portably.

> since it is now part of POSIX 2008.  We even tossed around an idea
> on IRC on how to implement it for mingw, details below.
>
> For now, I've got a test working on Linux and cygwin 1.7 as the golden
> reference (two independent implementations both satisfying the example
> from POSIX 2008), then for BSD systems with funopen(), a light-weight
> implementation that does all the work using stdio hooking (borrowing
> heavily from my cygwin implementation of open_memstream).  I'm posting
> the first two patches now, for any feedback, although the third patch
> for a heavy-weight implementation for Solaris, cygwin 1.5.x, and mingw
> will not be any sooner than Monday.
>
> For platforms without stdio hooking, the simplest thing we could think
> of is to create a temporary file under the hood, then provide gnulib
> overrides of fflush and fclose (the only two points at which POSIX
> requires that the original arguments to open_memstream are in sync
> with what has happened to the stream).  Those hooks would then dump
> the current contents of the temp file into malloc'd memory.  So it is
> I/O intensive, but seems feasible to implement.

Feasible indeed.
We don't care much about efficiency on deficient systems,
so this should be fine.
Eventually, they'll either catch up or die off.

> Other alternatives we
> considered were using mmap of a temporary file, and doing a gnulib
> override of malloc/realloc to recognize the mmap pointer, which is
> less I/O intensive but still requires the disk; but that runs into
> mmap difficulties (and makes mingw porting harder).  We also
> considered hooking every single function that takes a FILE* to
> understand string streams, but that was ruled out as too invasive to
> be practical.

Nice work.  Thanks!