Any ASCII character above 0x7F should be treated as UTF-8 in
ghostutils functions because GLib expects host names to be either
punycode encoded or in valid UTF-8 format.
The checks in gutf8.c already treat 0x80 as non-ASCII, but two checks
in ghostutils.c erroneously check for "great than" not "greater than or
equal to".
Clarify this by adding a new macro which is reused by PUNICODE_IS_BASIC
for better documentation in code.
If the build/test machine is slow, heavily-loaded or otherwise
inconvenienced, it might take a few seconds for the signal to be sent
by the subprocess, received by the message bus, re-broadcasted by the
message bus and received by the test code. Wait a few more seconds
before giving up.
If this test is successful, increasing this timeout will not slow it
down: we stop waiting for the signal as soon as we receive it. This will
only make any difference if the test would have failed.
Signed-off-by: Simon McVittie <smcv@debian.org>
We have two things happening in parallel:
1. The GDBus worker thread writes out an AddMatch call to the socket,
the message bus reads that method call from the other end of the
socket, and the message bus responds by adding the match rule
for the signal subscription
2. The main thread forks, and the child execs
gdbus-connection-flush-helper, which sends the signal that we are
expecting; the message bus receives that signal, and broadcasts it
to subscribers, if any
Normally (1.) wins the race because exec'ing a child process is more
time-consuming than IPC, and the test passes.
However, it is possible for (2.) to win the race. If so, we will never
receive the expected signal (because it was received by the message bus
before the AddMatch() method call, so at the time it was received, the
test was not yet a subscriber); the test waits until the timeout and
then gives up, and the test fails.
For whatever reason, Debian's s390x buildd seems to be reliably failing
this test since this week, having previously passed. I don't know what
changed. I can (very rarely) reproduce the race condition described
above on a developer-accessible s390x machine by repeatedly running the
/gdbus/connection/flush test in a loop.
Bug-Debian: https://bugs.debian.org/1115617
Signed-off-by: Simon McVittie <smcv@debian.org>
Make sure that results of build functions are stored in singletons to
avoid creating multiple instances which eventually could leak.
Fixes: #3784
(cherry picked from commit 18a7e7b4a2)
Co-authored-by: Tobias Stoeckmann <tobias@stoeckmann.org>
When get_help() gets ready to lay out the help text into columns,
it first goes through and computes the max_width of the strings in
the left column. Problem is, it measures the width of every
available option, whether or not they'll actually be displayed.
Instead, let's use the same criteria used when deciding whether
to display an option, to decide whether or not to account for it
when computing max_width. This way, the layout is sized for the
help that's actually being produced.
Fixes#3781
Always NUL-terminate the data, which g_file_get_contents does as well.
This fixes unnecessary fuzzer warnings.
For further clarification of this requirement, rename the internally
used function.
Fixes: #3783
Do what the comment states and strip all trailing slashes. Also, do not
strip the trailing slash if it's the only character left, i.e. if it
denotes the root directory.
XDG_CONFIG_DIR and HOME can be overridden with test environments. Read
these variables before building them again.
It's not possible to call the getter functions directly because the
caller of load_user_special_dirs already holds a lock and locking again
is undefined behavior and could lead to deadlocks.
Separate the functionality out into unlocked functions which definitely
have to be static to not expose them. Use them while holding the lock.
If the input string is too large on a 32 bit system, it is possible
to trigger an integer overflow which subsequently leads to an out of
boundary write.
Using the builtin multiplication checks leads to less instructions used
for these common functions (true for clang as well as gcc on x86_64).
Also, from a C perspective, the result is re-used, making code audits
easier.
With these adjustments, building with clang leads to no warnings:
- The "{ NULL }" statement could be replaced with "{ 0 }" to satisfy
clang, but this way it's explicitly filling all fields
- Even though "i" is not read with these g_array_binary_search calls,
it rightfully should be set
