bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: work in progress: [PATCH 0/2+] open_memstream
Date: Mon, 26 Apr 2010 10:18:44 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3

On 04/24/2010 12:45 AM, Eric Blake wrote:
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.  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.

We're at the point where every other function in mingw is being hooked.

Maybe it would be better to start fresh with ReactOS's msvcrt, add everything that gnulib provides and more (for example the *at functions could be added very easily), and link it statically with the application instead of using gnulib... kind of like the mingwex library but to the n-th power...

Paolo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]