open_memstream on non-linux?

[Lubomir I. Ivanov]

On 12 March 2013 10:35, 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.
>

that's certainly true.

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

yep, g_file_open_tmp() should do it, given g_file_open_tmp() succeeds.


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

we don't really need it. the only reason the POSIX memory stream is
used in the first place is because the save-xml API requires FILE
descriptor pointers, which i don't see GMemoryOutputStream supporting.
so tmpfile() is again a better solution even if we have to write a
temp file. also hacking about with FILE descriptors and cookies is an
option, but i doubt we can do it in a multi-platform way. i would
re-write the save-xml API to work with regular buffers all the way up
to a stage where a final fwrite() is used.

lubomir
--