Where it's easy add dummy args to match the cast; where the target is a subset just
prevent the warning with a cast to void*.
Provide a real copy function for the boxed type code in regress_foo.
This code is never executed afaics, but why not.
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
When building with Meson, we cannot set environment variables while
running custom targets and our builddir layout is different from
Autotools anyway.
Now g-ir-scanner and friends can autodetect when they're being run
uninstalled by Meson and will find _giscanner.so and the giscanner
python files in the build directory. This is very similar to what
gdbus-codegen uses in glib/gio.
Same for girepository/gdump.c.
glib_dep is what is actually needed to #include <glib.h>, not
gobject_dep. It works incidentally with system gobject/glib but not
when built via subprojects.
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)
This reverts commit e81c4681cc88a00fcd841c5a68d860d3714b55d7
The GI_TYPELIB_PATH envvar will still allow overriding the default
typelib dir (based on gobject-introspection libdir), but applications
will have the last say about typelib lookup directories. The resulting
lookup order is now:
- Paths added through g_irepository_prepend_search_path()
- Paths in GI_TYPELIB_PATH
- The default gobject introspection lookup dir
This makes g_irespository_prepend_search_path() work as announced
despite environment variables. If any application was relying on
GI_TYPELIB_PATH overriding the paths of this function call (for e.g.
make check, or to be able to run code inside the project tree), it
is encouraged to set up a similar envvar for their application specific
lookup dir, or perform this override through other means.
https://bugzilla.gnome.org/show_bug.cgi?id=765735
Due to an MSVC 2012 x64 compiler issue, the compiler generates bad code
for bdz.c, so the for loop in assign() continues running until the point
i falls below zero, causing an access violation when we try to do
curr_edge=queue[i]; (line 427 in bdz.c). Address this issue by breaking
out of the loop at the end of it when i reaches 0 after doing the
necessary processing.
https://bugzilla.gnome.org/show_bug.cgi?id=733595
These were leaking memory when dumping introspection data from projects
for building their GIR files. That’s generally not a problem, unless
you’re trying to build the project with -fsanitize=address, which causes
the GIR build phase to error out due to leaking memory.
https://bugzilla.gnome.org/show_bug.cgi?id=762653
This reverts commit 98bb6c91b710a95efe4cfeb303daeec3381b9c98.
It breaks programs simply executed *transitively* from a setuid
binary like the dbus daemon launch helper.
https://bugzilla.redhat.com/show_bug.cgi?id=1285991
Conflicts:
girepository/girepository.c
Add "n_field_callbacks" to ObjectBlob which represents the number of object
fields which are also callbacks. This a allows a constant time computation
for accessing sections after fields. Track writing of this field by passing
an extra argument through the girnode writers recursive call structure. This
essentally reverts a portion of commit 7027bb256d0d1ab which added a linear
time computation for accessing sections after fields.
Update typelib validator to also ensure n_field_callbacks is properly set.
https://bugzilla.gnome.org/show_bug.cgi?id=700338
Note that (direction [in]out) parameters are only pointers if the
underlying type being transferred is a pointer, i.e. if the formal
parameter is a pointer to a pointer or deeper.
https://bugzilla.gnome.org/show_bug.cgi?id=720201
We know of at least one privilege escalation path via
`GI_TYPELIB_PATH`. I don't want to audit for others. If someone
shows up with a use case we can talk.
https://bugzilla.gnome.org/show_bug.cgi?id=755472
This optimization is bugged and broken in the case of certain
libraries. GNOME uses a lot of prefixes with "G", so we'll almost always
have found the prefix.
This is specifically a problem for something like GXml.xDocument, which
uses a type name starting with a lower-case letter, which fools the
prefix logic, but we're also fooled by the "G" appearing in GLib and
Gio.
A more sophisticated version of this check would have three passes:
check prefix with type-case, check prefix without type-case, global
search, but this is an edge case and it doesn't feel worth it to write.
Generalize "throws" attribute to SignatureBlob which can be used by all
callable blob types. Keep FunctionBlob and VFuncBlob throw attributes
around and functional for compatibility. Refactor girwriter.c to write
out throws attribute for all callable types.
Based on a patch by Simon Feltman.
https://bugzilla.gnome.org/show_bug.cgi?id=729543
Add find_field utility function for finding a field info by name.
Beyond convenience, this should be faster than manually using
the get_n_fields and get_field functions because get_field does
an additional iteration for each field to calculate offsets O(n^2).
Thus find_field combines the offset and comparison
computations into a single loop O(n).
Based on a patch by Simon Feltman.
g_irepository_get_dependencies() is supposed to return the transitive
closure of all dependencies of the given namespace. However, it just
loads the dependencies field from the typelib, which is supposed to only
list immediate dependencies.
Introduce a new g_irepository_get_immediate_dependencies() which does
this, and rewrite g_irepository_get_dependencies() to build the
transitive closure of all its namespace dependencies. This does not
require loading any new typelibs, as the transitive closure of
dependencies should already have been loaded by g_irepository_require()
or g_irepository_load_typelib().
https://bugzilla.gnome.org/show_bug.cgi?id=743782
Make it clear that both the dependencies field in the typelib, and the
include elements in the GIR AST, are for immediate dependencies, not
transitive ones.
https://bugzilla.gnome.org/show_bug.cgi?id=743782
Use compiler directives for exporting symbols for the build of
libgirepository and also for the test libraries, like what is now done
in GLib and GTK+ so that maintaining a separate .symbols (and .def files)
would not be needed, in which the correct compiler directive is determined
during configure time. Drop all the .def files and the .symbols file as
we would not be using them anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=732669
This adds a header to the girepository library, which is then included
either directly or indirectly by the other headers so that all the public
symbols (and the 2 symbols in gitypelib-internal.h used by the tools) are
decorated by a macro, that can later be used to export the symbols and also
to be used to display compile-time warnings for usage of deprecated APIs,
which is like what is now being done in GLib (and GTK+, Clutter, and so
on).
This marks the first step that we begin to stop depending on the .symbols/
.def files to export the symbols.
https://bugzilla.gnome.org/show_bug.cgi?id=732669
This includes config.h in all the C-sources of girepository so that we can
get the correct export directive from config.h during compile time and
therefore export the symbols as necessary, like what GLib and GTK+ is
currently doing.
https://bugzilla.gnome.org/show_bug.cgi?id=732669
