Use g_slice to allocate instead of g_new(x, 1); It uses a memory
pool internally and should be faster, especially for GBaseInfo/GRealInfo,
structs which are tiny.
Make the language we use in the gtk-doc comments
more consistent. Add transfer annotation for all functions
returning a struct and mention how they should be freed.
This restores the reverted-commit ed8634d:
Author: Dan Winship <danw@gnome.org>
Date: Mon Apr 5 14:05:52 2010 -0400
g_callable_info_prepare_closure: handle mmap permissions error
When SELinux or similar is active, a process may not be able to mmap()
a segment that is both writable and executable, which would causing
g_callable_info_prepare_closure() to fail. Libffi has a workaround for
this problem though (it maps the same non-anonymous region twice, once
writable and once executable, and returns two separate pointers to
it), so use that.
But with an added fix, when using ffi_closure_alloc(), we need to use
ffi_prep_closure_loc() so we can pass in the executable address of the
trampoline separately from the writable address, rather than the
deprecated ffi_prep_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=615105
This reverts commit ed8634ddf73a56cb1935fd87254b3c6c04352893.
This commit caused crashes in gjs/gnome-shell, which we're still trying
to track down. See: http://bugzilla.gnome.org/615078
When SELinux or similar is active, a process may not be able to mmap()
a segment that is both writable and executable, which would causing
g_callable_info_prepare_closure() to fail. Libffi has a workaround for
this problem though (it maps the same non-anonymous region twice, once
writable and once executable, and returns two separate pointers to
it), so use that.
https://bugzilla.gnome.org/show_bug.cgi?id=614903
Foreign structs are special in the sense that there might
be native bindings (for instance PyCairo for PyGI) that provides
the same functionallity as the introspected variant.
https://bugzilla.gnome.org/show_bug.cgi?id=610357
To make things really better we should track the line origin of
element from the .gir file (and actually we need to do better
checking in the scanner), but this is slightly less lame.
When looking at an embedded type (e.g. a Callback after a Field), the
offset we put in the info structure was to the CallbackBlob itself.
However the code in g_type_info_get_interface assumed that the offset
was to a SimpleTypeBlob, which it wasn't.
https://bugzilla.gnome.org/show_bug.cgi?id=606180
We don't want to malloc each GIBaseInfo when they can be used in
function invocation; instead, allow stack allocation.
There were a lot of structure typedefs which were actually just
exactly the same as GIBaseInfo, with the one exception of GITypeInfo.
Instead, just put the single GITypeInfo boolean inside GIBaseInfo
as a bit in a bitfield.
GIBaseInfo is still opaque publicly; GIRealInfo is the new
internal structure.
Using this, add new functions to retrieve arguments and argument types
on the stack.
https://bugzilla.gnome.org/show_bug.cgi?id=604074
Rather than having bindings use g_function_info_invoke, which is basically
a toy/demo API, export a convenience utility function which takes the introspection
information and sets up things we need to pass to libffi.
Then invocation can be done directly to libffi by a binding.
As part of this work, remove some (unused by gjs) public functions from the
girffi API, and instead export a function to map to libffi which can work
semi-correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=604074
Due to a missing header, gobject-introspection fails to compile on OpenBSD.
And only due to headers-including-headers practice this doesn't blow up on
many other platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=596226
In the case where a known class derives from a hidden one, we want
to use the most-derived parent class, rather than simply falling back
to GObject.
Example:
ShellEmbedWidget in gnome-shell derives from ClutterGLXTexturePixmap from clutter,
which is a hidden class. ClutterGLXTexturePixmap's parent itself is
ClutterX11TexturePixmap, which is also hidden. But its parent is
ClutterTexture, which we do know. Use that.
https://bugzilla.gnome.org/show_bug.cgi?id=598993
We are treating GIUnresolvedInfo as a GIBaseInfo, but the structures
had drifted out of sync. Add a repository pointer and bring them
back into sync.
Based on a report and patch from Jan Hudec <bulb@ucw.cz>
It's was busted that g_typelib_new_* does the dlopen() since that caused
g-ir-compiler to load the modules even though it wasn't going to do
anything with them.
Instead, change things so that g_module_symbol does the dlopen on-demand.
Remove the extra dlopen(NULL) inside girepository.c, we had another
already in gtypelib.c.
Thanks to Owen Taylor for suggesting this approach.
