At that point in the code, len can only be 0, 1 or 2. The code below is
a no-op if (len == 0), so the condition is pointless.
Remove it, and we should be able to achieve full branch coverage of
gbase64.c.
This should introduce no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
While I’m here, we might as well check that we output what the RFC says
we should output.
https://tools.ietf.org/html/rfc4648#section-10
(We do.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Relax a precondition in g_base64_encode_step() to allow this. It’s valid
to base64 encode an empty string, as per RFC 4648.
Similarly for g_base64_decode(), although calling it with a NULL string
has never been allowed. Instead, clarify the case of calling it with an
empty string.
This includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1698
The caller needs to check this themselves in any case, so we might as
well at least follow convention in defining the precondition.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Commit 084e1d868 added a preallocation to an array to avoid
reallocations later on, but neglected the fact that after N insertions
into the array, there’s always a NULL terminator added to the end. Fix
the preallocation to include that NULL terminator.
This doesn’t change the correctness of the code, but should eliminate
one reallocation.
Spotted by Sebastian Dröge. See
https://gitlab.gnome.org/GNOME/glib/merge_requests/674.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
res_ninit() requires the __res_state struct passed to it to be
zero-filled on FreeBSD.
Spotted and analysed by Ashish SHUKLA.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes#1697
There are some cases where valgrind turns up leaks that are already
suppressed in the file, but with a slight difference at the top of the
stack. Add suppressions for these cases as well.
Synchronize access to cancelled flag of cancellable, which was
previously access without synchronization in g_cancellable_is_cancelled.
Use atomic operations instead of existing global mutex, to avoid
serializing calls to g_cancellable_is_cancelled across all threads.
Ensure that source is attached to the context before it migth be used
from another thread, since otherwise operation on source are
unsynchronized and not thread-safe.
In particular there was a data race between g_source_attach and
g_source_set_ready_time (used from g_file_monitor_source_handle_event).
GValue g_type field is used for synchronization with g_once_init_enter,
and so it should be written to only with g_once_init_leave.
Replace structure copy with memcpy that copies the one remaining field
of GValue, i.e., data array.
This essentially reverts commit
cffed58737.
The preceding two commits have fixed the test so it’s no longer flaky.
The following command gives 5000 passes in a row for me:
meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1679
It’s occasionally possible for the cancellation of the service to happen
before connection_cb() gets scheduled in the other thread. The
locking/unlocking order of mutex_712570 requires:
• test_threaded_712570(): lock mutex
• test_threaded_712570(): start wait loop
• connection_cb(): lock mutex
• test_threaded_socket_service_finalize(): unlock mutex
• test_threaded_712570(): end wait loop
• test_threaded_712570(): unlock mutex
Fix that by quitting the main loop once connection_cb() has been called
(i.e. once the server thread has received the incoming connection
request), rather than just after the client thread (main thread) has
sent a connection request.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
On about 1 in 3 test runs, the socket-service would fail with the
ref_count assertion in connection_cb() failing (the ref_count would be 3
rather than the expected 2).
This was happening because the GTask from
g_socket_listener_accept_socket_async() now always takes at least one
main context iteration to return a result (whereas before
6f3d57d2ee it might have taken zero), but
the ref_count can drop below 3 before the process of returning a result
starts. During the process of returning a result, the ref_count
temporarily increases again, which is what was breaking the test.
Fix this by waiting for one more main context iteration. This is a bit
of a hack, but the real fix would be to expose the outstanding_accept
boolean from GSocketService as public API (which the test can
interrogate), and that seems too much like exposing internal state.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
Almost everything that needs gioenumtypes.h also needs
gobjectenumtypes.h. Fixes:
ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
In file included from ../gio/win32/gwin32filemonitor.h:25:0,
from ../gio/win32/gwin32filemonitor.c:26:
../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
#include <gobject/gobjectenumtypes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIO modules built with MSVC do not begin with 'lib', but they can
begin with 'gio'. Without this, you can only load GIO modules built
with MSVC that are `name.dll`, not `gioname.dll`.
Compilers get confused when variables are initialized by a function by
taking them as reference in an out argument; this, coupled with the fact
that C does not initialize variables by default, most commonly results
in a "maybe uninitialized" compiler warning.
