G_RESOURCE_OVERLAYS is a list of resource-path and filesystem-path pairs.
Since on Windows filesystem paths use ':', this list can't be ':'-separated
there. Fix that by making it ';'-separated on Windows. Make the parser
error clearer (we're not looking for a slash, we're looking for an absolute
path).
If a URI can't be handled by by WinHTTPVfs, it should pass that URI
along to the URI parser of the wrapped Vfs, not to its generic parser.
Theoretically, generic parser should also be able to handle URIs,
but this is subject to Vfs semantics.
In case of Windows, the wrapped Vfs is GLocalVfs, which is *local* and
treats any generic names as either file:// URIs or as filesystem
paths. It only ever treats URIs as URIs when they are passed
to its URI parser. This breaks the testsuite when g-icon GIO test passes
unhandleable sftp:// URI, and expects it to come through unmolested,
yet GLocalVfs, getting that URI as a generic parse name, treats it as
a filesystem path, and then "canonicalizes" it by prepending CWD.
Fix this by making WinHTTPVfs pass any URIs it gets to the URI parser
of the wrapped Vfs. This way unknown URIs remain URI-ish. This seems
like a reasonable things to do, since the URI parser should not be
given anything other than URIs, so there's no reason to try generic
parsing with these strings.
Closes: #875
The g_string_insert_len method accepts '-1' for its len parameter,
as a shorthand for strlen(val). Likewise the various convenience
wrappers around it also accept -1. This was not documented, leaving
developers to wonder why len is a gssize, instead of gsize.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Previously once the end of addresses was reached it would return
NULL even if it was waiting on a dns response. Now it will keep
waiting so all addresses are received.
Fixes#1680
Currently, the actual asynchronous work, represented by
asynchronous_cancellation_run_task, was over before the GCancellable
could be triggered. While that doesn't invalidate the purpose of the
test, since it's fundamentally about cancellation, it would be
nicer if the cancellation actually served some purpose instead of
being a mere formality.
https://gitlab.gnome.org/GNOME/glib/issues/1608
When calling g_socket_listener_accept_socket_async() on a
GSocketListener with multiple sockets, the accept_ready() callback is
called for the first incoming connection on each socket. It will return
success/failure for the entire accept_socket_async() GTask, and then
free the GSources for listening for incoming connections on the other
sockets in the GSocketListener. The GSources are freed when the GTask is
finalised.
However, if incoming connections arrive for multiple sockets within the
same GMainContext iteration, accept_ready() will be called multiple
times, and will call g_task_return_*() multiple times, before the GTask
is finalised. Calling g_task_return_*() multiple times is not allowed.
Propagate the first success/failure, as before, but then ignore all
subsequent incoming connections until the GTask is finalised.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Once cancelled, a GTask's callback should not only be invoked
asynchronously with respect to the creation of the task, but also with
respect to the GCancellable::cancelled handler. This is particularly
relevant in cases where the cancellation happened in the same thread
where the task is running.
Spotted by Dan Winship and Michael Catanzaro.
Closes https://gitlab.gnome.org/GNOME/glib/issues/1608
It needs investigating and fixing properly, but let’s not let it disrupt
the CI in the meantime.
Follow-up in https://gitlab.gnome.org/GNOME/glib/issues/1679.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When parsing GVariant text format strings, we do a limited form of type
inference. The algorithm for type inference for nested array child types
is not complete, however (and making it complete, at least with a naive
implementation, would make it O(N^2), which is not worth it) and so some
text format arrays were triggering an assertion failure in the error
handling code.
Fix that by making the error handling code a little more relaxed, in the
knowledge that our type inference algorithm is not complete. See the
comment added to the code.
This includes a test case, provided by oss-fuzz.
oss-fuzz#11578
Signed-off-by: Philip Withnall <withnall@endlessm.com>
And add tests.
There wasn’t actually a bug on x86_64 before, but it was making use of
undefined behaviour, and hence triggering ubsan warnings. Make the code
more explicit, and avoid undefined behaviour.
oss-fuzz#12686
Signed-off-by: Philip Withnall <withnall@endlessm.com>
__func__ is part of the C99 standard.
__FUNCTION__ is another name for __func__. Older versions of GCC
recognize only this name. However, it is not standardized.
For maximum portability, Its recommended to use __func__.
__PRETTY_FUNCTION__ is yet another name for __func__. However, in C++,
__PRETTY_FUNCTION__ contains the type signature of the function as
well as its bare name
http://gcc.gnu.org/onlinedocs/gcc/Function-Names.htmlhttps://gitlab.gnome.org/GNOME/glib/issues/535
To make things consistent across the board as that is the WinSock2 error
code that is received by g_socket_send_message_with_timeout() when it
returns G_POLLABLE_RETURN_WOULD_BLOCK.
This uses newer methods that support more folders such as Downloads. The
Objective-C code is in a separate file, gosxutils.m.
Based on !85 by Patrick Griffis.
They were changed in 6a2cfde2 to reuse the G_MAXINT values but
parsing nexted macros is currently broken in g-i and results in wrong
values.
Add value annotations for g-i to override the values.
This also moves the annotations to the macro definitions to have
everything g-i uses in one place.
