GitLab

Lukas Oberhuber authored Jan 11, 2022 and Philip Chimento committed Jan 12, 2022

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.

Marco Trevisan authored Apr 09, 2021 and Emmanuele Bassi committed Jan 11, 2022

We can use them in Gjs to verify whether a value is properly packed
and unpacked to GValue.

Marco Trevisan authored Apr 09, 2021 and Emmanuele Bassi committed Jan 11, 2022

It's the only basic type missing, better to have for consistency.

Marco Trevisan authored Apr 09, 2021 and Emmanuele Bassi committed Jan 11, 2022

We want to be able to test whether it's possible to convert two
different fundamental types through GValue, so add a function for this.

Marco Trevisan authored Apr 08, 2021 and Emmanuele Bassi committed Jan 11, 2022

This can be used to test we don't do unexpected conversions between
invalid types.

Marco Trevisan authored Apr 08, 2021 and Emmanuele Bassi committed Jan 11, 2022

A fundamental type may or may not provide set and get value functions,
the regress implementations always provide one, so define a new type
with no such functions so that we can test this case in Gjs.

To avoid repeating lots of duplicated code, we re-use the same
functions of RegressTestFundamentalObject when possible, by using the
same structure.

Newer versions of the GNU libc have started to warn if the result of the
call is unused.

The hack that copies the doctemplates directory into the build
directory has stopped working with newer versions of Meson; while it's
possible to copy files, custom_target() cannot depend on a directory.
Additionally, the dependency has always been broken.

Instead, we enumerate the template files—after all, it's not like they
change a lot—and then we list them as dependencies for the test targets.

Fixes: #414

We are going to use additional API that is only available since 0.57,
but since 0.57 is a very old version, let's skip it.

We can find the templates directory using the module file once
installed, but when running uninstalled we need to have a way to specify
where the templates can be found in the sources directory.

Emmanuele Bassi authored Apr 08, 2020 and Emmanuele Bassi committed Jan 09, 2022

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

Don't use a real function to describe optional/nullable differences, to avoid getting into
the weeds when it comes to edge cases.

Fixes: #211

Remove mentions of Autotools: we only support Meson.

Fixes: #327

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.

Cimbali authored Nov 02, 2021 and Emmanuele Bassi committed Nov 23, 2021

Legacy logic, except:
- on linux with recent libffi
- on macOS with AMD64 architectures

Cimbali authored Nov 01, 2021 and Emmanuele Bassi committed Nov 23, 2021

Deprecate the previous API as per discussion in !283.

Sergei Trofimovich authored Jul 17, 2021 and Emmanuele Bassi committed Nov 23, 2021

Commit 6bab939b ("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(): gjs#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>

Sergei Trofimovich authored Jun 27, 2021 and Emmanuele Bassi committed Nov 23, 2021

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:

    https://github.com/libffi/libffi/commit/9ba559217bea0803263a9a9a0bafcf9203606f5b

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

GJS now maps GLib.ByteArray and GLib.Bytes to Uint8Array whenever
possible. Change the string returned by docwriter for devdocs to
reflect that.

The pcre subproject in GLib was renamed, so we need to fix the
incantation that promotes the subproject in our own CI.

Do not use the snapshot of the old developer.gnome.org website.

Do not use the snapshot of the old developer.gnome.org website; we
generate and publish the API reference ourselves.

Those types should map by definition to guintptr and gintptr.

They are fairly common in Rust cbindgen projects, which maps
usize->uintptr_t for ex.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

GLib 2.70 has just been released, so let's sync up the documentation and
annotations.

Fixes: #402