We attempted to return a value in void-return-type functions in both
gicallableinfo.c and gitypeinfo.c, so avoid that since that will trigger a
C4098 warning on Visual Studio, which is considered an error if we are building
against an installed version of GLib 2.68.x or later.
This will fix builds against GLib-2.68.x and later on Visual Studio.
This adds gi_type_tag_argument_from_hash_pointer() and
gi_type_tag_hash_pointer_from_argument(). They do the same thing as
the corresponding g_type_info_... functions, which are used to pack and
unpack the correct field of a GIArgument into/from a data pointer in
GHashTable or GList, regardless of machine architecture or endianness.
These functions take a GITypeTag obtained from
g_type_info_get_storage_type(), instead of a GITypeInfo pointer. (The
storage type is the only piece of data that is actually used from the
GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead.
The original g_type_info_... functions are reimplemented in
terms of the new g_type_tag... functions.
We can just update the for loop condition to be >0 for all builds, which
is actually equivilant to >=1 as we are essentially comparing an
unsigned 32-bit int, so that we don't need to worry about fixing the
VS2012 bug invasively, as Visual Studio 2012 x64 is more sensitive about
sizes of variables (e.g. pointer sizes in this case)
The __ia64 and __x86_64__ macros are defined for GCC but not Visual
Studio, but actually this code path should also be taken for Visual
Studio when doing a 64-bit build (x86_64/x64 and aarch64/arm64, _WIN64
will be defined for these cases), since Windows is an LLP64 platform.
This will avoid C4311/C4312 warnings on Visual Studio builds, which are
often warnings of concern as we are dealing with pointers with differing
sizes on 32-bit and 64-bit Windows builds.
Later GLib versions assume that warning C4715 is an error as we want ot
be sure that functions that return a value do indeed return one by all
means.
Avoid this warning by adding a 'return 0' in brz_search_packed(), it
might be pointless but does indeed avoid the warning.
This new API does the same thing as gi_type_info_extract_ffi_return_value,
but takes a GITypeTag instead of GITypeInfo pointer, and additionally a
GIInfoType if the GITypeTag is GI_TYPE_TAG_INTERFACE. (These pieces of
data are the only things used from the GITypeInfo structure.)
It's intended for bindings using an argument cache, such as GJS and
PyGObject, so that they don't have to store a whole 64-bit GITypeInfo
pointer in their cache in many common cases, and can just store the 5-bit
type tag instead, or the 5-bit interface type in case of
GI_TYPE_TAG_INTERFACE.
The original gi_type_info_extract_ffi_return_value() is reimplemented in
terms of the new gi_type_tag_extract_ffi_return_value().
The documentation comment for SimpleTypeBlob seemed to imply that a basic
type was embedded if the reserved fields were nonzero. After examining the
code, I believe that was actually due to some words missing, and the
comment should say that the type is embedded if the fields are zero.
This is a convenience for bindings that want to perform a similar action
for all numeric types. It allows more expressive code in some cases:
if (GI_TYPE_TAG_IS_NUMERIC(tag)) {
do_one_thing();
return;
}
switch (tag) {
case GI_TYPE_TAG_ARRAY:
do_other_thing();
return;
/* ... */
default:
g_assert_not_reached();
}
instead of listing out all of the numeric types in the switch statement.
If a <GType invalid> (that's the way it appears in python's debugger) is
returned, `g_type_name` returns NULL. This
function therefore returns NULL at this time
as subsequent calls to `strlen( data->gtype_name)` segfault.
Some functions are meant to exist for the entire duration of the
process, and thus have no need for a notification function because
one will never be called.
Fixes: #49
On macOS, @-prefixed shlib paths (@rpath, @executable_path, and
@loader_path) need to be treated as absolute. Trying to combine them
with a configured library path produces a mangled path that is
unresolvable and may cause unintended side effects (such as loading
the library from a fall-back location on macOS 12.0.1).
Libgirepository is not GLib, and it should not use GLIB_DEPRECATED,
GLIB_DEPRECATED_FOR, and GLIB_UNAVAILABLE macros (as the GLib
documentation clearly states).
When using them, we don't get the proper macro expansion, so deprecated
symbols suddenly disappear from our shared library.
Commit 6bab939bf ("girffi.c: fix return value for g_callable_info_prepare_closure()")
effectively changes semantics of return value from code pointer to data pinter (closure).
`gjs` (and probably other software) relies on old (incorrect) semantics of
g_callable_info_prepare_closure(): https://gitlab.gnome.org/GNOME/gjs/-/issues/428
This change exposes the API that allows extracting directly
callacble code pointer. `gjs` will have to adapt to the new API.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
The initial failure was observed on `meld` against recently released
`libffi-3.4-rc1`. There `meld` crashes as:
```
$ meld
Segmentation fault (core dumped)
$ gdb --args /usr/bin/python3.9 /usr/bin/meld
(gdb) run
...
Thread 1 "python3.9" received signal SIGSEGV, Segmentation fault.
0x00007fffe9ac1ae8 in g_callable_info_free_closure (
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
428 g_free (wrapper->ffi_closure.cif->arg_types);
(gdb) bt
callable_info=0x555555d45990, closure=0x7fffe9e70c20)
at ../gobject-introspection-1.68.0/girepository/girffi.c:428
data=0x555555d252d0)
at ../pygobject-3.40.1/gi/pygi-closure.c:635
...
```
The bug here is in type mismatch between expected return value of
`g_callable_info_prepare_closure()` and actual value (executable
code pointer):
```c
ffi_closure * g_callable_info_prepare_closure(...) {
gpointer exec_ptr;
...
status = ffi_prep_closure_loc (&closure->ffi_closure, cif, callback, user_data, exec_ptr);
return exec_ptr;
}
```
Note: `exec_ptr` is a code pointer that could be directly executed by
caller, like `((rt (*)(a1,a2))exec_ptr)(1,2);` It should never be wrapped
into an `ffi_closure*`, which is normally called via `ffi_call(closure, ...)`.
We see the problem when we try to free direct code pointer instead of
`ffi_closure()` as starting from libffi-3.4 executable trampoline and
`ffi_closure()` don't necessarily live in the same block:
9ba559217b
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
A GObject property can be accessed generically through the GObject API,
e.g. g_object_set_property() and g_object_get_property(). Properties
typically also have public accessor functions, which are (according to
our own best practices) called through the generic API.
The introspection data is currently missing the relation between a
property and its public accessor functions. With this information, a
language binding could, for instance, avoid exposing the C API entirely,
thus minimizing the chances of collisions between property names and
accessor functions; alternatively, a binding could call the C API
directly instead of going through the generic GObject API, thus avoiding
the boxing and unboxing from a native type to a GIArgument and finally
into a GValue, and vice versa.
In the GIR, we add two new attributes to the `property` element:
- setter="SYMBOL"
- getter="SYMBOL"
where "symbol" is the C function identifier of the setter and getter
functions, respectively. The `setter` attribute is only applied to
writable, non-construct-only properties; the `getter` attribute is only
applied to readable properties.
We maintain the ABI compatibility of the typelib data by using 20 bits
of the 25 reserved bits inside the PropertyBlob structure. The data is
exposed through two new GIPropertyInfo methods:
- g_property_info_get_setter()
- g_property_info_get_getter()
which return the GIFunctionInfo for the setter and getter functions,
respectively.
We introduce two new annotations:
- (set-property PROPERTY_NAME)
- (get-property PROPERTY_NAME)
These annotations are valid inside function blocks for methods on
objects and interfaces, and define whether a function is a property
accessor, e.g.:
/**
* gtk_widget_set_name: (set-property name)
* @self: ...
* @name: ...
*
* ...
*/
/**
* gtk_widget_get_name: (get-property name)
* @self: ...
*
* ...
*
* Returns: ...
*/
The annotations are transformed into the GIR data as attributes:
- glib:set-property="PROPERTY_NAME"
- glib:get-property="PROPERTY_NAME"
The underlying typelib data has had flags for setter and getter
functions for a while, but they have never been plugged into the GIR
data or the introspection scanner. Now they are; you can retrieve the
GIPropertyInfo from a GIFunctionInfo that has the GI_FUNCTION_IS_SETTER
or GI_FUNCTION_IS_GETTER flags set.
Fixes: #13
A "final" class is a leaf node in a derivable type hierarchy, and cannot
be derived any further.
This matches the changes in libgobject that introduced G_TYPE_FLAG_FINAL
to the type flags.
Because of skepticism I received in #224, I made this PR which keeps the
testsuite and CI improvements but doesn't add any new build options. I
hope this would be less controversial:
- no new knobs
- tests for those using existing build options
- CI tests `build_introspection_data = false`
Up to now, section annotations had to match a class or interface
name in order to be serialized in the gir.
With this commit, they now get serialized as docsection nodes,
for potential use by documentation tools.
`g_win32_output_stream_new_from_fd()` is private in Gio.
It's normally not exported unless `GLIB_STATIC_COMPILATION` is effective.
PS. Why would i not be called `GIO_STATIC_COMPILATION` for Gio .c-files?
