GNOME Bugzilla – Bug 666854
Make GMappedFile a GBytes
Last modified: 2013-03-18 03:33:15 UTC
GMappedFile is in essence a GBytes with a custom constructor, so i would be nice if it was using the GBytes api. It would also mean i didn't have to use the ugly ref_user_data and unref_user_data stuff in: http://git.gnome.org/browse/glib/commit/?h=resources&id=c1f3e9297b71472ea35ecc01b5a7179150c07a7a As gvdb could just always store a GBytes.
Here is what gtimezone.c does: tz->zoneinfo = g_bytes_new_with_free_func (g_mapped_file_get_contents (file), g_mapped_file_get_length (file), (GDestroyNotify)g_mapped_file_unref, g_mapped_file_ref (file)); But looking at http://git.gnome.org/browse/glib/commit/?id=eea6042f5f4db2f123763097ac2fd4738cef24ee we also attempted to make GMappedFile compatible with direct use as GBytes
They are not actually compatible any more though, as in GMappedFile free_func is before ref_count, but not in GBytes. Not sure how that matters though, as neither type is publically exposed, so we can change the internals anyhow we want. Maybe it would make more sense to typedef GMappedFile to GBytes (after all they have exactly the same contents) and then deprecate all the g_mapped_file_* calls that are non-constructors for the corresponding g_bytes_* call.
Alex: that's pretty much exactly what I hoped would eventually happen.
We'll have to add #ifdef G_OS_WIN32 HANDLE mapping; #endif to make this work
*** Bug 670141 has been marked as a duplicate of this bug. ***
The only problem I can see is that a GBytes is supposed to be immutable, while we allow creating a writable GMappedFile. I guess we could just deprecate writability? Or say that you need to g_bytes_unref_to_array() if you want a mutable thing? Of course just casting the result of g_bytes_get_data() from const to non-const works too :-) Anyway, I pushed a proposal to wip/mapped-bytes branch.
See also https://bugzilla.gnome.org/show_bug.cgi?id=677065
closing this, since we have get_bytes now