open_memstream on non-linux?

Miika Turkia miika.turkia at gmail.com
Tue Mar 12 02:03:29 PDT 2013


On Tue, Mar 12, 2013 at 10:35 AM, Martin Gysel <me at bearsh.org> wrote:
> Am 11.03.2013 18:09, schrieb Lubomir I. Ivanov:
>> On 11 March 2013 18:19, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> There is some discussion and code on working around that here…
>>>
>>> http://stackoverflow.com/questions/10305095/can-i-replace-a-call-to-open-memstream-with-a-malloc-and-an-implicit-cast
>>>
>>> which looks way overkill to me.
>>>
>>> Miika - any way you could reimplement this differently? :-)
>>
>> here is my attempt for miika's reference.
>>
>> it also now, uses ./ for the temp zip file, since obviously /tmp/
>> isn't portable to non-UNIX OS. instead i would write the temp file in
>> the home directory, which we should retrieve in a OS specific way
>> using e.g. subsurface_get_home_path().
>
> For me it seems to be a bad idea to create a tmp file in the home
> directory, just image, if subsurface crashes once a tmp file has been
> created, it will never get deleted again. there's a reason places like
> /tmp are there.
>
> looking through the glib's documentation I found
> g_mkstemp() or g_file_open_tmp().
> g_file_open_tmp() for example takes a filename template (no directory)
> creates and opens a tmp file in the appropriate location. it also gives
> you the actual name of the file based on the template. there's no
> mention that this doesn't work on windows...
>
> to workaround the open_memstream() problem, you could use a
> GMemoryInputStream and a GMemoryOutputStream from gio which can be used
> as dynamic growing stream which provides the needed io functions
>
> I could implement it myself but not today... (diving ;))

Thanks for the pointers, I'll take a look at them tonight if I just
have time for it.

miika


More information about the subsurface mailing list