Replace the hand-written equivalent of this with the call to the
GHashTable built-in version to save a few lines of code.
The GResource code was written a couple of years before this function
existed.
Similarly, replace a set-mode usage of g_hash_table_insert() with a call
to g_hash_table_add().
https://bugzilla.gnome.org/show_bug.cgi?id=765668
Resources are always little endian, so the gvdb is byteswapped. When looking
up the value, it would return a new byteswapped variant, making the data
returned from do_lookup() invalid once that variant is unref'd. Since
byteswapping doesn't matter for the "ay" data anyway, just use
gvdb_table_get_raw_value() instead and only byteswap the length and flag
values.
https://bugzilla.gnome.org/show_bug.cgi?id=673409
This bug was exposed by fixing the following leak in the resources test:
==29204== 11,456 (84 direct, 11,372 indirect) bytes in 1 blocks are definitely lost in loss record 859 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x41E5E29: g_converter_input_stream_new (gconverterinputstream.c:204)
==29204== by 0x4228D38: g_resource_open_stream (gresource.c:363)
==29204== 7,192 (76 direct, 7,116 indirect) bytes in 1 blocks are definitely lost in loss record 855 of 861
==29204== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==29204== by 0x4084724: standard_malloc (gmem.c:85)
==29204== by 0x40847C7: g_malloc (gmem.c:159)
==29204== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==29204== by 0x409B227: g_slice_alloc0 (gslice.c:1029)
==29204== by 0x41936CF: g_type_create_instance (gtype.c:1872)
==29204== by 0x417CCC9: g_object_constructor (gobject.c:1839)
==29204== by 0x417C6F4: g_object_newv (gobject.c:1703)
==29204== by 0x417CC5A: g_object_new_valist (gobject.c:1820)
==29204== by 0x417C1DB: g_object_new (gobject.c:1535)
==29204== by 0x424E815: g_zlib_decompressor_new (gzlibdecompressor.c:270)
==29204== by 0x4228DD8: g_resource_lookup_data (gresource.c:422)
==27020== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in loss record 684 of 936
==27020== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27020== by 0x4084724: standard_malloc (gmem.c:85)
==27020== by 0x40847C7: g_malloc (gmem.c:159)
==27020== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==27020== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==27020== by 0x40B5277: g_variant_get_variant (gvariant.c:749)
==27020== by 0x4273182: gvdb_table_value_from_item (gvdb-reader.c:478)
==27020== by 0x42731E8: gvdb_table_get_value (gvdb-reader.c:509)
==27020== by 0x4228B36: do_lookup (gresource.c:280)
==27020== by 0x4228F56: g_resource_get_info (gresource.c:492)
==26427== 24 bytes in 1 blocks are definitely lost in loss record 608 of 965
==26427== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==26427== by 0x4084724: standard_malloc (gmem.c:85)
==26427== by 0x40847C7: g_malloc (gmem.c:159)
==26427== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==26427== by 0x40BC038: g_variant_get_child_value (gvariant-core.c:969)
==26427== by 0x40BA89F: g_variant_valist_get (gvariant.c:4482)
==26427== by 0x40BAC23: g_variant_get_va (gvariant.c:4681)
==26427== by 0x40BAB29: g_variant_get (gvariant.c:4633)
==26427== by 0x4228BA5: do_lookup (gresource.c:293)
==26427== by 0x4228F51: g_resource_get_info (gresource.c:493)
We need to do this because constructors run before main() and
thus before any call to g_mem_set_vtable, making it impossible to
use that function if constructors call g_malloc.
We do this by making the constructors just register the static data
for lazy registration, doing the lazy registration when using
the global resource set.
It's hardly useful to bloat the resource data with blanks intended only
for human readability, so add a preprocessing option that uses xmllint --noblanks
to strip these.
Bug #667929.
GResource is a bundle of files combined into a single binary blog.
The API lets you access the files the resource contains by
using resource paths. You can also register resources with a
global list and access these globally in a merged resource namespace.
The normal way this is used is to link in the resources into your
application/library and have it be automatically registred.
Resources are compiled from an xml description using
glib-compile-resources.
