| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
hashv is unsigned, no need to check if >= 0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows (Visual Studio at least), unsigned longs are always 4 bytes,
on both 32-bit and x64 Windows, so we cannot use unsigned longs to deal
with pointers on 64-bit builds, as pointers are 8 bytes on 64-bit
Windows, which may well render the pointer (which we acquired from
libffi) invalid.
This will fix crashes in PyGObject which are manifested when launching
the cairo-demo example sript (intermittent) and when clicking on
"Interactive Dialog" button in the Dialog demo in the PyGObject GTK+
Code demos before entering anything in Entry 1 and Entry 2, when running
on x64 Visual Studio builds of the GTK+/PyGObject stack.
Also use size_t instead of unsigned long in gthash.c when we check that
memory & 0x3 is 0, to silence compiler warnings from enabling /Wp64,
which is used to detect portability problems on Visual Studio when
doing x86->x64 code builds.
https://bugzilla.gnome.org/show_bug.cgi?id=702788
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This patch silences another gtkdoc-mkdb warning.
https://bugzilla.gnome.org/show_bug.cgi?id=688418
|
| |
|
|
|
|
|
|
|
| |
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
|
