Clang seems to apply more rigorous type checks across the different
arguments to the atomic builtins. Fix various
`-Wincompatible-pointer-types`, `-Wpointer-sign` and `-Wint-conversion`
warnings.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This makes calls to g_signal_connect_data() and g_signal_connect_object()
with default flags more self-documenting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes code that sets no flags a bit more self-documenting:
using G_TYPE_FLAG_NONE makes it clearer that no special behaviour is
required than literal 0, and clearer that there is no weird casting
between types than (GTypeFlags) 0.
GTypeFlags and GTypeFundamentalFlags occupy the same namespace and the
same bitfield, so I intentionally haven't added
G_TYPE_FUNDAMENTAL_FLAGS_NONE.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The references to gint and guint were copy/pasted from
g_atomic_int_exchange(), but what we want here is a gpointer, gintptr
or guintptr like the rest of the g_atomic_pointer_ family.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Atomic primitives allow to do conditional compare and exchange but also
to get the value that was previously stored in the atomic variable.
Now, we provided an exchange function that allows to do an exchange if
the atomic value matches an expected value but we had no way to know
at the same time what was the value in the atomic at the moment of the
exchange try, an this can be useful in case that the operation fails,
for example if the current value is still acceptable for us, allowing
to do a kind of "OR" check:
gint old_value;
gint valid_value = 222;
while (!g_atomic_pointer_compare_and_exchange_value (&atomic,
valid_value, 555,
&old_value)
{
if (old_value == 555 || old_value == 222)
valid_value = old_value;
}
Despite the name, the call was still doing blocking operations when
looking for app handlers via GAppInfo. Now it's possible to use fully
async calls.
Together with previous commit, the API is now fully async.
Despite the name, we still used blocking calls to get the default app
for URI, now that we have an async implementation of the API to get the
default implementation for URI scheme, we can remove the blocking calls.
We did not check whether this function worked before, so add a simple
test case for it, providing some test functions to make it possible to
reply the same behavior
In some cases (such as in our CI tests) we may not have any dbus session
set after launching, but we always assumed so.
In case we have not a session bus set, we only have to return early.
In both callbacks of g_file_query_default_handler_async() we were
actually using I/O blocking APIs making it not fully async.
Now that such API is provided, we can use it.
While it's possible to create a directory synchronously via
g_dir_make_tmp(), there's no such API that performs it asynchronously.
So implement it using GFile, using a thread to perform such task.
Avoid re defining cases for GIoErrorEnum when we already handle them
through GFileError, so remove code duplication and just rely on
g_file_error_from_errno() to compute the file error and then use
g_io_error_from_file_error() to get the possible IOError.
In case it's something not handled as GFileError, we can use the same
logic as before.
This is now a safe change to do as we have covered all the supported
cases in tests.
Listing a user in `glib.doap` is important for ensuring their access
rights are correct in GitLab (as they are synced from the DOAP file by a
sysadmin script).
When `CODEOWNERS` was written, we were assuming that GNOME’s GitLab
would get support for the `CODEOWNERS` feature in GitLab. Unfortunately,
that’s not happened, and it remains an enterprise-only feature.
As such, that means that listing a co-maintainer of GLib in `CODEOWNERS`
is not sufficient to grant them permissions to actually merge MRs or
triage issues. That means they can’t really do any co-maintaining.
So fix that by updating the DOAP from `CODEOWNERS`. This doesn’t change
the list of co-maintainers at all, or the amount of trust assumed of
anybody.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
As with commit 0932f71460, which did this for refs/unrefs of the
object in `g_object_notify()`, we need to do a similar thing for
refs/unrefs of the instance with `g_signal_emit()`, for all the same
reasons.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
