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>
__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.
This code was a persistent source of `-fsanitize=thread` errors
when I was trying to use it on OSTree.
The problem is that while I think this code is functionally correct,
we hold a mutex during the writes, but not the reads, and TSAN (IMO
correctly) flags that.
Reading this, I don't see a reason we need a mutex at all. At the
cost of some small code duplication between posix/win32, we can just
pass the data we need down into each implementation. This ends up
being notably cleaner I think than the awkward "lock/unlock to
serialize" dance.
(Minor review changes made by Philip Withnall <withnall@endlessm.com>.)
https://gitlab.gnome.org/GNOME/glib/issues/1224
