It doesn't make sense for a proxy resolver to return NULL without an
error on the first call. Whereas a DNS resolver would do this to
indicate that a query completed successfully but found no results, a
proxy resolver should return "direct://" instead. Therefore, if we are
going to return NULL, we ought to have an error as well. Let's make sure
this actually happens by adding some fallback errors just in case
GProxyResolver feeds us weird results.
Additionally, we should not return any errors except
G_IO_ERROR_CANCELLED after the very first iteration. This is an API
contract of GSocketAddressEnumerator. Let's add some checks to ensure
this.
Note that we have inadequate test coverage for GProxyAddressEnumerator.
It's tested here only via GSocketClient. We could do a bit better by
testing it directly as well. For example, I've added tests to see what
happens when GProxyResolver returns both a valid and an invalid URI, but
it's not so interesting here because GSocketClient always uses the valid
result and ignores the error from GProxyAddressEnumerator.
Fixes#2597
This has no practical impact, since it's only a test, and none of the
test code would have hit this bug, but the GTestProxyResolver's check to
see if the URI scheme is simple:// currently only compares the first
four bytes of the string, so it's actually only checking for the "simp"
and would match anything else after that, e.g. "simpleton://". This is
surely not intended.
This part of test_non_utf8_printf() was missed while converting other
test expectations to look for a figure space, probably because it is
only run if a legacy ja_JP.eucjp locale exists. Debian generates a fairly
comprehensive set of locales (including some that are non-UTF-8) while
running GLib's installed-tests, so this was caught by CI.
Fixes: 7074122 "gdatetime: Pad numbers with numeric space"
Signed-off-by: Simon McVittie <smcv@debian.org>
Creating a `GAppInfo` from a commandline isn’t currently supported on
macOS, but the implementation was incorrectly returning `NULL` without
setting the `GError`.
This was being caught by the new tests in `gio/tests/file.c`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
On macOS the comparison was failing as one of the paths had a trailing
slash while the other didn’t.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
