This reverts commit 280c8d41fb.
It breaks the unit tests on macOS (see #3314) and no fix has been
forthcoming.
The alternate stack changes can be resubmitted once they include a
working unit test on macOS, as evidently its treatment of alternate
stacks differs from that on Linux, and hence needs testing.
Helps: #3314
Some applications, toolkits or languages may define an alternative stack
to use for traces. This is for example the case of go.
So, in case an application defines an alternate signal stack, GLib should
use that instead of the default one to receive signals otherwise it may
break the application expectations and write where it's not allowed to.
The python interpreter found by `/usr/bin/env python3` is not
necessarily the same installation as the one that's found by meson's
`pymod.find_installation('python')`. This means that even though meson
is checking that the python installation it found includes the
'packaging' module, the scripts might not have access to that module
when run.
For distribution packaging, it's usually desirable to have python script
interpreters be fully specified paths, rather than use `/usr/bin/env`,
to ensure the scripts run using the expected python installation (i.e.
the one where the python 'packaging' dependency is installed).
The easiest way to fix this is to set the script interpreter to the
`full_path()` of the python interpreter found by meson. The specific
python interpreter that will be used can be selected through the use of
a meson machine file by overriding the "python" program. Many
distributions already have this set up using meson packaging helpers.
This fixes an issue with the number getting very big due to
CPU_ISSET not returning exactly 0 or 1.
This also fixes scenarios where there are holes in the CPU
set. E.g. for a simple run like `taskset --cpu-list 1,2,4 ...`
the old code would return 2 instead of 3, due to iterating
until `ncores` (which is 3) and therefore not accounting for
CPUs further in the set.
Ref https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3784
This is put together through git archaeology:
```
git log -- glib/tests/dataset.c
```
The following commits were too trivial to have meaningful copyright:
- 1a2c5e155d
- ea06ec8063
- 0178402c6d
- e3d1869ee3
- c34cc2348c
- d15e6f7c9c
- de8672fe0b
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The dataset tests are using a subprocess to catch possible deadlocks
within the `test_datalist_clear()` test. However, that’s causing
occasional spurious test failures on the slower CI runners, where the
subprocess can take longer than 500ms to run due to the machine being
overloaded.
Remove the subprocess from the test, and allow the test to deadlock if
it fails. The Meson test harness has a timeout for catching things like
this.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For those projects that cannot use `g_autoptr()`, GStrvBuilder's end
plus unref is not really convenient.
We can crib the "unref to data type" model from GBytes, and have an
additional unref function that also returns the just built GStrv.
If our GPollFunc is set to g_poll() then we can optionally use a poll()
alternative with higher precision. ppoll() provides poll() equivalence
but with timeouts in nanoseconds.
With more precise polling timouts, frame clocks and other timing sensitive
APIs are not restricted to a minimum of 1 millisecond timeout.
This gets access to the timeout as microseconds up until we are about to
enter the GPollFunc. This is useful so that alternative means may be used
to poll with more precision for timeout.
This was erroring on recent GCC because `struct heap_dict` is smaller than
the publicly provided size (guintptr[16]) in the header for GVariantDict.
Port to use `g_malloc()` directly, and use a static assertion to ensure
we’re allocating the larger of the two struct sizes.
These consistently fail on scheduled CI runs, which is not helping our
ability to catch Hurd regressions.
For example, https://gitlab.gnome.org/GNOME/glib/-/jobs/3709402
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: #3148
It may not be obvious, but the moment unlock is called, the locker
instance may be destroyed.
See g_object_unref(), which calls toggle_refs_check_and_ref_or_deref().
It will check for toggle references while dropping the ref count from 2
to 1. It must decrement the ref count while holding the lock, but it
also must still unlock afterwards.
Note that the locker instance is on the object itself. Once we decrement
the ref count we give up our reference and another thread may race
against destroying the object. We thus must not touch object anymore.
How can we then still unlock?
This works correctly because:
- unlock operations must not touch the locker instance after unlocking.
- assume that another thread races g_object_unref() to destroy the
object, while we are about to call object_bit_unlock() in
toggle_refs_check_and_ref_or_deref(). Then that other thread will also
need to acquire the same lock (during g_object_notify_queue_freeze()).
It thus is blocked to destroy the object.
Add code comments about that.
These unfortunately have `gchar*` return types rather than `const
gchar*`. This is a historical artifact which we can’t change: while
adding `const` would only be an API break and not an ABI break, it would
cause all sorts of C++ code which uses GLib to emit new cast warnings
(similarly, C code with const correctness compiler warnings enabled
would do the same).
The incorrect return type causes the GIR scanner to (reasonably) assume
the return value is allocated, which is wrong.
Fix that by explicitly adding `(transfer none)`.
Also add an explicit `(nullable)` because all three functions are.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3286
Partially because the use of `G_GSIZE_MODIFIER` breaks translatable
string extraction (issue #3271) and partially because `g_format_size()`
produces more human-readable results anyway.
Prior to commit cf5e371c67 the code was using `%lu`, so this is a fairly
new issue.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3271
PCRE2 10.43 has now introduced support for variable-length lookbehind,
so these tests now fail if GLib is built against PCRE2 10.43 or higher.
See
e8db6fa713/ChangeLog (L94).
Rather than making the tests conditional on the version of PCRE2 in use,
just remove them. They are mostly testing the PCRE2 code rather than
any code in GLib, so don’t have much value.
This should fix CI runs on msys2-mingw32, which updated to PCRE2 10.43 2
days ago.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It's helpful for the assertion message to say what we were expecting and
what we actually got. It's also useful to have g_test_message()
diagnostics to indicate how far into the test we were.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we didn't test these at all, which made it hard to determine
whether %Ec, %EC had appropriate output on platforms where era-based
dates are unsupported. Now we do, and we can observe that on platforms
with no support for era-based dates, %c matches %Ec and %C matches %EC,
as desired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I can't read Japanese, but these match the output of:
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%c' | iconv -f eucjp -t UTF-8
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%C' | iconv -f eucjp -t UTF-8
which seem like a reasonable thing to use as a reference.
According to Google Translate, 平成 refers to the Heisei era, which was
current during 2009, and seems unreasonable to expect as output on a
platform where era-based dates are unsupported.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3252
Signed-off-by: Simon McVittie <smcv@collabora.com>
Maintain them in separate lists within `meson.build`. This makes no
functional difference at the moment, but will be used in an upcoming
commit to generate separate GIR files per platform.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This reverts commit 50d432c77b.
The platform-specific headers of GLib and Gio are now introspected
separately, so the documentation for them can be built separately, and
this workaround is no longer needed.
Helps: #3037
The docs for this should match the docs for `g_unix_open_pipe()`, which
it calls.
Inspired by !3911.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Using FD_CLOEXEC here is now deprecated. Keep exactly one call with
FD_CLOEXEC, in test_pipe_fd_cloexec().
Signed-off-by: Simon McVittie <smcv@collabora.com>
The copy of this function that moved to glib-unix.c still needs to
implement the fdwalk-style interface, but this copy does not, allowing
us to turn it into a very simple syscall wrapper. Its remaining callers
never check for errors, and it never failed anyway, so remove the
returned value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These are the same as Linux `close_range (lowfd, ~0U, 0)` and
`close_range (lowfd, ~0U, CLOSE_RANGE_CLOEXEC)`, but portable.
Unlike some implementations of BSD closefrom(3), they are
async-signal-safe.
The implementations were moved from the GSpawn code, which already
needs all of this functionality anyway, with the exception of
set_cloexec() which was copied (leading to some minor duplication,
but it's very simple).
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3247
Signed-off-by: Simon McVittie <smcv@collabora.com>
They don’t need to be listed there in order to be built, and doing so
just means they get pulled into the `g-ir-scanner` command for building
`GLib-2.0.gir` and their contents end up being listed as public
introspectable API, which is not what we want.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3231
Otherwise, `CFLAGS='-Wall -Werror' meson build` fails with:
...
Command line: `cc ./glib/build/meson-private/tmp7iwplrgi/testfile.c -o ./glib/build/meson-private/tmp7iwplrgi/output.obj -c -O3 -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
stderr:
./glib/build/meson-private/tmp7iwplrgi/testfile.c: In function 'main':
./glib/build/meson-private/tmp7iwplrgi/testfile.c:83:21: error: unused variable 'y' [-Werror=unused-variable]
83 | long double y = frexpl (x, &exp);
| ^
cc1: all warnings being treated as errors
-----------
Checking if "frexpl prototype can be re-listed" compiles: NO
glib/gnulib/meson.build:316:2: ERROR: Problem encountered: frexpl() is missing or broken beyond repair, and we have nothing to replace it with
It’s reasonable for the `main()` function in a test suite to pass
ownership of some test data to `g_test_add_data_func_full()`, along with
a `GDestroyNotify`, and rely on GTest to free the data after all tests
have been run.
Unfortunately that only worked if the test was run, and not skipped
before its test function was called. This could happen if, for example,
it had `/subprocess` in its path.
Fix that by always freeing the test data. This required reworking how
tests are skipped, slightly, to bring all the logic for that within
`test_case_run()`, so that it could always handle the memory management.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3248
The function arguments index_ and length could lead to a sum which is
larger than G_MAXUINT, possibly leading to out of boundary accesses
in array_remove_range functions.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Fixes: #3240
It's not obvious why we wouldn't use g_quark_try_string(). Add a code
comment that this is intentional and a reference for how to find out
more.
Also, fix typo in another code comment.
The amount of used memory should stay in relation to the number of
entries we have. If we delete most (75%) of the entries, let's also
reallocate the buffer down to 50% of its size.
datalist_append() now starts with 2 elements. This works together with
the shrinking. If we only have one entry left, we will shrink the buffer
back to size 2. In general, d->alloc is always a power of two (unless it
overflows after G_MAXUINT32/2, which we assume will never happen).
The previous buffer growth strategy of never shrinking is not
necessarily bad. It has the advantage to not require any checks for
shrinking, and it works well in cases where the amount of data actually
does not shrink (as we'd often expect).
Also, it's questionable what a realloc() to a smaller size really
brings. Is that really gonna help and will the allocator do something
useful?
Anyway. This patch introduces shrinking. The check for whether to shrink
changes from `if (d->len == 0)` to `if (d->len <= d->alloc / 4u)`, which
is probably cheap even if most of the time we don't need to shrink. For
most cases, that's the only change that this patch brings. However, once
we find out that 75% of the buffer are empty, calling realloc() seems a
sensible thing to do.
The main point here is to reuse datalist_remove() and datalist_shrink().
Especially, datalist_shrink() will become more interesting next, when it
actually shrinks the buffer.
Also, I find the previous implementation with "data_end" confusing.
Instead, only use index "i_data" to iterate over the data.
Extract helper functions datalist_remove() and datalist_shrink(). This
is to reduce duplicate code, but also to have a default way how to do
this.
In particular, later datalist_shrink() might do more aggressive
shrinking. We need to have that code in one place.
g_datalist_unlock() is probably faster than g_datalist_unlock_and_set().
Move the "if (data)" check (that we anyway had) earlier, so we can
call g_datalist_unlock() and return early.
If too many keys are requested, they temporary buffer is allocated
on the heap. There is no problem in principle, to remove more than
16 keys.
Well, the problem is that GData tracks entries in a linear list, so
performance will degrade when it grows too much. That is a problem,
and users should be careful to not add unreasonably many keys. But it's
not the task of g_datalist_id_remove_multiple() to decide what is
reasonable.
This limitation was present from the beginning, in commit 0415bf9412
('Add g_datalist_id_remove_multiple'). It's no longer necessary since
commit eada6be364 ('gdataset: cleanup g_data_remove_internal()').
GDataSet is mainly used by GObject. Usually, when we access the private
data there, we already hold another lock around the GObject.
For example, before accessing quark_toggle_refs, we take a
OPTIONAL_BIT_LOCK_TOGGLE_REFS lock. That makes sense, because we anyway
need to protect access to the ToggleRefStack. By holding such an
external mutex around several GData operations, we achieve atomic
updates.
However, there is a (performance) use case to update the qdata
atomically, without such additional lock. The GData already holds a lock
while updating the data. Add a new g_datalist_id_update_atomic()
function, that can invoke a callback while holding that lock.
This will be used by GObject. The benefit is that we can access the
GData atomically, without requiring another mutex around it.
For example, a common pattern is to request some GData entry, and if
it's not yet allocated, to allocate it. This requires to take the GData
bitlock twice. With this API, the callback can allocate the data if no
entry exists yet.
also, make the global variable "static const". That may allow the linker
to place the variable into read-only memory, so we are a bit more confident
that it cannot be modified.
g_strndup() internally uses strncpy(), while g_strdup() uses memcpy().
Most likely, memcpy() is faster.
Instead of strlen()+g_strndup(), use g_strdup() as we don't need the
length.
This fixes many things from the port to gi-docgen, but also improves
documentation more generally.
Main improvements/fixes:
- Fix links to functions, constants, etc.
- Rewrite code syntax to work with Markdown
- Reduce indentation (do not indent by 4 to prevent code blocks)
- Remove redundant text such as "can be NULL" or "should be freed"
- Move text from large return info texts to main function text
- Remove periods at the end of parameter and return descriptions
- Do not capitalize the first word of a parameter or return description
- Try to improve consistency between docs for similar functions
- Convert %TRUE and %FALSE into true and false
- Convert other uses of `%` and `#` into inline code
Helps: #3037
Fixes broken links, and removes `%` and `#` notation in favor of inline
code, and limits indentation to two to prevent accidental formatting.
Fixes some style issues too, mainly removing periods at the end of
parameter and return descriptions.
Also removes trailing whitespace from the doc comments.
Helps: #3037
Saying that a GtkWidget is a GtkWidget is trivially true, but not the
point we were trying to make here.
Fixes: b5c07063 "docs: Use code for class names in links"
Signed-off-by: Simon McVittie <smcv@collabora.com>
The test cancellation timeout was being tested twice, once only when run
with `-m thorough`. Seems a bit pointless.
Merge the two tests and use the smaller timeout values from the two, so
the test suite doesn’t run any more slowly than it did.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`g_test_init()` needs to be called before custom command line handling
so it has a chance to strip out the arguments it handles.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This avoids four coredumps being processed for every run of the
`testing` unit tests (which test `GTest`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It is common to declare a mutex locker variable and to not use it in the
scope. That causes clang to warn about unused variable which is not
entirely true since the cleanup function IS the intended usage.
Work around that issue with a new macro that uses G_GNUC_UNUSED and
has the extra advantage of being less verbose.
Fixes: #3223.
FreeBSD iconv by default handles input characters that are not
representable in the destination character set by emitting a replacement
character such as '?'. While this appears to be the POSIX mandated
behaviour it does not match GNU behaviour and causes the gconvert test
to fail in the `test_one_half` testcase. Fortunately FreeBSD provides a
iconvctl flag to request this behaviour to match GNU iconv.
See https://github.com/freebsd/freebsd-src/commit/7c5b23111c5fd199204
Usually, after g_pointer_bit_lock() we want to read the pointer that we
have. In many cases, when we g_pointer_bit_lock() a pointer, we can
access it afterwards without atomic, as nobody is going to modify the
pointer then.
However, gdataset also supports g_datalist_set_flags(), so the pointer
may change at any time and we must always use atomics to read it. For
that reason, g_datalist_lock_and_get() does an atomic read right after
g_pointer_bit_lock().
g_pointer_bit_lock() can easily access the value that it just set. Add
g_pointer_bit_lock_and_get() which can return the value that gets set
afterwards.
Aside from saving the second atomic-get in certain scenarios, the
returned value is also atomically the one that we just set.
In all cases after taking the lock with g_datalist_lock(), we also
get the pointer. And it hardly makes sense otherwise.
Replace g_datalist_lock() by g_datalist_lock_and_get() which does
both steps in one.
- only use gnewa0() for up to 400 bytes (arbitrarily chosen as
something that is probably small enough to cover most small tasks
while fitting easily on the stack). Otherwise fallback to g_new0().
- don't do intermediate G_DATALIST_SET_POINTER(). Set to NULL
afterwards with g_datalist_unlock_and_set().
- move the g_free(d) after releasing the lock on datalist.
- when setting datalist to NULL, do it at the end with
g_datalist_unlock_and_set() to avoid the additional atomic
operations.
- when freeing the old "d", do that after releasing the bit
lock.
The previous code was in practice correct.
(((guintptr) ptr) | ((gsize) mask))
works even if gsize is smaller than guintptr. And while the C standard
only guarantees that cast between uintptr_t and void* works, on
reasonable compilers it works to directly cast uintptr_t to GData*.
Still, no need for such uncertainty. Just be clear about the involved
types (use guintptr throughout) and cast first to (gpointer).
g_datalist_clear_i() had only one caller, altough the code comment made
it sound as if in the past there were more.
A function that has only one caller, and then needs a code comment to
explain the context in which it is called, makes the code more complicated
than necessary.
Especially since the function expects to be called with a global lock
held, and then unlocks and relocks. Spreading such things to another
function (which is only used once) makes code harder to follow.
Inline the function, so that we can see all the (trivial) code at one place.
This saves an additional atomic set.
Also, changing the pointer before the unlock can awake a blocked thread,
but at this point, the lock is still held (and the thread may need to
sleep again). This can be avoided.
The existing g_pointer_bit_lock() and g_pointer_bit_unlock() API
requires the user to understand/reimplement how bits of the pointer get
mangled. Add helper functions for that.
The useful thing to do with g_pointer_bit_lock() API is to get/set
pointers while having it locked. For example, to set the pointer a user
can do:
g_pointer_bit_lock (&lockptr, lock_bit);
ptr2 = set_bit_pointer_as_if_locked(ptr, lock_bit);
g_atomic_pointer_set (&lockptr, ptr2);
g_pointer_bit_unlock (&lockptr, lock_bit);
That has several problems:
- it requires one extra atomic operations (3 instead of 2, in the
non-contended case).
- the first g_atomic_pointer_set() already wakes blocked threads,
which find themselves still being locked and needs to go back to
sleep.
- the user needs to re-implement how bit-locking mangles the pointer so
that it looks as if it were locked.
- while the user tries to re-implement what glib does to mangle the
pointer for bitlocking, there is no immediate guarantee that they get
it right.
Now we can do instead:
g_pointer_bit_lock(&lockptr, lock_bit);
g_pointer_bit_unlock_and_set(&lockptr, lock_bit, ptr, 0);
This will also emit a critical if @ptr has the locked bit set.
g_pointer_bit_lock() really only works with pointers that have a certain
alignment, and the lowest bits unset. Otherwise, there is no space to
encode both the locking and all pointer values. The new assertion helps
to catch such bugs.
Also, g_pointer_bit_lock_mask_ptr() is here, so we can do:
g_pointer_bit_lock(&lockptr, lock_bit);
/* set a pointer separately, when g_pointer_bit_unlock_and_set() is unsuitable. */
g_atomic_pointer_set(&lockptr, g_pointer_bit_lock_mask_ptr(ptr, lock_bit, TRUE, 0, NULL));
...
g_pointer_bit_unlock(&lockptr, lock_bit);
and:
g_pointer_bit_lock(&lockptr, lock_bit);
/* read the real pointer after getting the lock. */
ptr = g_pointer_bit_lock_mask_ptr(lockptr, lock_bit, FALSE, 0, NULL));
...
g_pointer_bit_unlock(&lockptr, lock_bit);
While glibc is fine with it (and returns a `NULL` pointer), technically
it’s implementation-defined behaviour according to POSIX, so it’s best
avoided.
See
https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html.
In particular, valgrind will warn about it, which is causing failures of
the gdbus-codegen tests when valgrind is enabled. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/3460673 gives
```
==15276== posix_memalign() invalid size value: 0
==15276== at 0x484B7BC: posix_memalign (vg_replace_malloc.c:2099)
==15276== by 0x49320B2: g_variant_new_from_bytes (gvariant-core.c:629)
==15276== by 0x4931853: g_variant_new_from_data (gvariant.c:6226)
==15276== by 0x4B9A951: g_dbus_gvalue_to_gvariant (gdbusutils.c:708)
==15276== by 0x41BD15: _foo_igen_bat_skeleton_handle_get_property (gdbus-test-codegen-generated.c:13503)
==15276== by 0x41BFAF: foo_igen_bat_skeleton_dbus_interface_get_properties (gdbus-test-codegen-generated.c:13582)
…
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3228
This doesn't appear to work reliably on s390x and ppc64, returning
the results that were expected without %E or intermittently crashing.
It seems that on little-endian 64-bit, the intptr_t returned by the
undocumented _NL_TIME_ERA_NUM_ENTRIES correctly has the number of entries
in its low-order half (at the time of writing, 0x0000'0000'0000'000b for
Japan), but on big-endian 64-bit, it has the number of entries in its
high-order half instead (for example 0x0000'000b'0000'0000 for Japan),
with the low-order half being all-zero or possibly uninitialized.
Making this reliable will require some sort of defined API from glibc.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3225
Bug-Debian: https://bugs.debian.org/1060735
Signed-off-by: Simon McVittie <smcv@collabora.com>
We only care about the introspection data for documentation purposes;
the GStaticMutex and GStaticRecMutex types are long since deprecated,
and they cannot be used from language bindings anyway, so their size is
immaterial.
Fixes: #3222
Previously, the girs and typelibs generated from gobject-introspection
ommited the deprecated apis, however we want them annotated for
documentation purposes.
Skip the deprecated gthead api so they do not make it into the
typelibs which caused problems as not all the symbols exist.
See https://gitlab.gnome.org/GNOME/gjs/-/issues/595
Introduce g_log_writer_syslog() that is suitable for use as a
GLogWriterFunc and sends the log message to the syslog daemon.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
_Thread_local is also C11, so possibly other compilers would also support
it.
However, since not *all* compilers support it, it can anyway only be
used as optimization and conditional asserts. As such, the current
detection based on __GNUC__ to only support gcc (and clang) is good
enough.
This was done manually, but the changes are very repetitive. There are
some minor rewordings/formatting tweaks included. The bulk of the
changes are to the linking syntax.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
There is no reason for key and value to have different annotations.
Both may return NULL as a valid value.
gpointer typed parameters are nullable by convention, so there is
no change here. The (nullable) annotation is just for humans really.
To make it match its definition and documentation comment. This fixes a
g-ir-scanner warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Extended error domains can never be unregistered, so these closures
have to be around forever.
Fixes some g-ir-scanner warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
`GByteArray` is a bit odd in that it allows call-chaining. All the
instances of that were missing a `(transfer none)` annotation though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This fixes a warning from g-ir-scanner as the declaration and
documentation comment didn’t match.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
