[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: work in progress: [PATCH 0/2+] open_memstream
From: |
Jim Meyering |
Subject: |
Re: work in progress: [PATCH 0/2+] open_memstream |
Date: |
Sat, 24 Apr 2010 12:35:29 +0200 |
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!
- work in progress: [PATCH 0/2+] open_memstream, Eric Blake, 2010/04/23
- [PATCH 1/2] open_memstream-tests: new module, Eric Blake, 2010/04/23
- [PATCH 2/2] open_memstream: new module, Eric Blake, 2010/04/23
- Re: work in progress: [PATCH 0/2+] open_memstream,
Jim Meyering <=
- Re: extended streams, Bruno Haible, 2010/04/24
- Re: work in progress: [PATCH 0/2+] open_memstream, Paolo Bonzini, 2010/04/26
- [PATCH 3/2] open_memstream: port to more systems, Eric Blake, 2010/04/26