If not done, it would leak the memory as address sanitizer reports:
==1294==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fa7a94b7602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x44c7a7 in __config_new girepository/cmph/cmph_structs.c:11
#2 0x44aaa7 in cmph_config_new girepository/cmph/cmph.c:291
#3 0x446fb5 in _gi_typelib_hash_builder_prepare girepository/gthash.c:114
#4 0x406cf7 in add_directory_index_section girepository/girmodule.c:270
#5 0x409ee6 in _g_ir_module_build_typelib girepository/girmodule.c:546
#6 0x404ada in main tools/compiler.c:217
#7 0x7fa7a70d482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
==4091==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7fc20c854602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x44a3f3 in cmph_io_vector_new girepository/cmph/cmph.c:228
#2 0x44a965 in cmph_io_vector_adapter girepository/cmph/cmph.c:276
#3 0x446f9f in _gi_typelib_hash_builder_prepare girepository/gthash.c:113
#4 0x406cf7 in add_directory_index_section girepository/girmodule.c:270
#5 0x409ee6 in _g_ir_module_build_typelib girepository/girmodule.c:546
#6 0x404ada in main tools/compiler.c:217
#7 0x7fc20a47182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
The typelib compiler was writing uninitialised memory to the output file.
There were two sources of this uninitialised memory: the hash writer included
some uninitialised memory in its output, and the bytes added after the hash
output for padding were also not being initialised.
Fix this by passing the padded size to the hash code writer function and
having that function initialise the entire memory region to zero before
writing.
https://bugzilla.gnome.org/show_bug.cgi?id=721177
It appears that cmph library can return (n+1) when querying item not
present in its original n-item-sized set. Adjust code so that it
detects this condition and do not chase stray pointers resulting from
this bogus(?) hash result.
https://bugzilla.gnome.org/show_bug.cgi?id=675939
In multiple places in the typelib, but most importantly the directory,
we need some fast indexing. Perfect hashing, as implemented by CMPH
(previous commit), is an exact fit for the problem domain.
Add an API built on top of CMPH which maps strings->guint16 (we just
need a guint16 for the typelib index).
https://bugzilla.gnome.org/show_bug.cgi?id=554943
