Adds tests to cover this case and similar cases for various GResource
methods in future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/927
In the vast majority of cases, we can avoid temporary
allocations for paths in g_resources_enumerate_children().
In the case we need to add a suffix "/", we can usually just
build the path on the stack. In other cases, we can completely
avoid the strdup, which appears to only have been added for
readability. If the path is really long, we fallback to doing
what we did before, and use g_strconcat().
In the case of Builder, this saved 5.3mb of temporary
allocations in the process of showing the first application
window.
https://bugzilla.gnome.org/show_bug.cgi?id=790275
Previously, the path canonicalization for resources had liberal use of
strlen() and memmove() while walking through the path. This patch avoids
any secondary strlen() and removes all use of memmove().
A single allocation is created up front as we should only ever need one
additional byte more than then length of the incoming path string.
To keep the implementation readable, the mechanics are kept in external
functions. memrchr() was not used due to its lack of portability.
This is faster in every test case I've tested. Paths that contain
relative ../ have the most speedup.
https://bugzilla.gnome.org/show_bug.cgi?id=790310
We need to use g_content_type_get_mime_type() to look up the mime type of
the file from the registry on the content type that was acquired on
Windows, as g_file_info_get_content_type() does not acquire the
file mime type (unlike on *NIX).
g_content_type_get_mime_type() on *NIX is more or less an no-op as it
simply returns the g_strdup()-ed version of the passed-in content type.
This will enable the resources test to pass on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
==1265== 84 (8 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 793 of 827
==1265== at 0x4029467: calloc (vg_replace_malloc.c:467)
==1265== by 0x408479B: standard_calloc (gmem.c:104)
==1265== by 0x4084846: g_malloc0 (gmem.c:189)
==1265== by 0x4084B2D: g_malloc0_n (gmem.c:385)
==1265== by 0x4228A98: g_resource_load (gresource.c:253)
==1265== by 0x804A56D: test_resource_registred (resources.c:198)
==509== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 828 of 837
==509== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==509== by 0x4084724: standard_malloc (gmem.c:85)
==509== by 0x40847C7: g_malloc (gmem.c:159)
==509== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==509== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==509== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==509== by 0x804A48C: test_resource_data (resources.c:174)
==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)
==28778== 700 (20 direct, 680 indirect) bytes in 1 blocks are definitely lost in loss record 842 of 863
==28778== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28778== by 0x4084724: standard_malloc (gmem.c:85)
==28778== by 0x40847C7: g_malloc (gmem.c:159)
==28778== by 0x409B1E1: g_slice_alloc (gslice.c:1003)
==28778== by 0x405396B: g_bytes_new_with_free_func (gbytes.c:173)
==28778== by 0x405390D: g_bytes_new_take (gbytes.c:122)
==28778== by 0x804C2B1: test_uri_query_info (resources.c:435)
==28318== 38 (12 direct, 26 indirect) bytes in 1 blocks are definitely lost in loss record 613 of 865
==28318== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==28318== by 0x4084724: standard_malloc (gmem.c:85)
==28318== by 0x40847C7: g_malloc (gmem.c:159)
==28318== by 0x4084AB4: g_malloc_n (gmem.c:361)
==28318== by 0x4229599: g_resources_enumerate_children (gresource.c:806)
==28318== by 0x804B39E: test_resource_registred (resources.c:283)
==27820== 31 bytes in 1 blocks are definitely lost in loss record 587 of 866
==27820== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==27820== by 0x4084724: standard_malloc (gmem.c:85)
==27820== by 0x40847C7: g_malloc (gmem.c:159)
==27820== by 0x4084AB4: g_malloc_n (gmem.c:361)
==27820== by 0x409D6A1: g_strdup (gstrfuncs.c:356)
==27820== by 0x4069FF7: g_get_current_dir (gfileutils.c:2544)
==27820== by 0x804BCA7: test_resource_module (resources.c:370)
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
