They’re causing the CI to fail. While someone familiar with FreeBSD
investigates the failure, it’s easiest to disable all C11-style atomics
than add more preprocessor checks to only disable the atomics added in
!1123.
If nobody can fix the new C11-style atomics before the 2.64.0 release,
this commit should be reverted and a more comprehensive set of preprocessor
checks put in place to essentially revert !1123 for BSD only.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1940
In glib/gutf8.c there was an UB in function g_utf8_find_prev_char when
p == str. In this case we substract one from p and now p points to a
location outside of the boundary of str. It's a UB by the standard.
Since this function are meant to be fast, we don't check the boundary
conditions.
Fix glib/tests/utf8-pointer test. It failed due to the UB described
above and aggressive optimisation when -O2 and LTO are enabled. Some
compilers (e.g. GCC with major version >= 8) create an optimised version
of g_utf8_find_prev_char with the first argument fixed and stored
somewhere else (with a different pointer). It can be solved with either
marking str as volatile or creating a copy of str in memory. We choose
the second approach since it's more explicit solution.
Add additional checks to glib/tests/utf8-pointer test.
Closes#1917
If a transient worker thread calls it, the allocated memory is
definitely leaked when the thread exits. That’s intentional.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If a transient worker thread calls it, the allocated memory is
definitely leaked when the thread exits. That’s intentional.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We cannot just call
G_PARAM_SPEC_GET_CLASS (pspec)->value_set_default (pspec, &dflt_value);
without initializing the GValue first. It would call
param_string_set_default(), which would set the pointer value
to a cloned string (which later never gets released, because
the GValue is not known to hold a string).
Fixes: 6ad799ac67
Commit 7678b107 seems to have left the GHashTable pretty printer with an
off-by-one error, skipping the first key it encounters and printing an
extra garbage key/value pair instead. This fixes that by moving an
increment to the end of a loop rather than the beginning.
This ensures that when running many instances of the test in parallel,
they don’t collide in the same current directory, and hence spuriously
fail. This can happen when writing `out.xbel`, for example.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1930
In general, we should aim to always check a `GError` before checking a
boolean, since the error message from the `GError` gives us a lot more
information about failure, which helps with debugging.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The time handling was assuming that the test would complete in the same
second as it started, which was not always true.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1930
`g_assert_*()` gives more useful messages on failure, and isn’t compiled
out by `G_DISABLE_ASSERT`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When choosing the type to base `size_t` on, check the compatibility of
passing pointers, as well as the width of the type, to avoid compiler
warnings in future.
For now, the code to do the checks is fairly ugly due to limitations in
Meson. In particular, the new checks are limited to gcc and clang (other
compilers will behave as before), and they are all duplicated. See the
comments in the code for links to Meson improvement requests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1777
Similar to 3837b83f, glibc memcmp is declared with the first two
arguments annotated as non-null via an attribute, which results in the
undefined behaviour sanitizer considering it to be UB to pass a null
pointer there (even if we are comparing 0 bytes, and hence not actually
dereferencing the pointer).
This shows up in /gvariant/serialiser/children when run with the
undefined behaviour sanitizer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Similar to 3837b83f, glibc memcmp is declared with the first two
arguments annotated as non-null via an attribute, which results in the
undefined behaviour sanitizer considering it to be UB to pass a null
pointer there (even if we are comparing 0 bytes, and hence not actually
dereferencing the pointer).
This shows up in /gvariant/serialiser/children when run with the
undefined behaviour sanitizer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Tools like this should be configurable in a cross or native file. In
particular, if we are cross-compiling (with an executable wrapper like
qemu-arm), the build system ld is not necessarily able to manipulate
host system objects.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise we'll never test the EXTERNAL-only mode, because that relies
on testing the private macros
G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED and
G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED.
Fixes: 9f962ebe "Add a test for GDBusServer authentication"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This bypasses any issues we might have with containers where IPv6 is
returned by name resolution (particularly since GNOME/glib!616) but
doesn't necessarily actually work.
This comes at a minor test-coverage cost: we don't test GDBusServer's
default behaviour when told to listen on "tcp:" or "nonce-tcp:", and
on systems where IPv6 is available, we don't test it. If we want to
do those, we should perhaps do them in separate tests, and disable
those tests when binding to ::1 doesn't work.
Mitigates: GNOME/glib#1912
Signed-off-by: Simon McVittie <smcv@collabora.com>
kdeinit5 overwrites argv, which in turn results in /proc/self/cmdline
being overwritten. It seems that this is done in a way that does not
necessarily guarantee that /proc/self/cmdline will end up NUL-terminated.
However, g_file_get_contents() is documented to fill a buffer of size
len + 1, where buffer[len] == '\0', even if the file's actual contents
(from buffer[0] to buffer[len-1] inclusive) did not include a NUL;
so we can safely relax this assertion slightly.
Resolves: https://gitlab.gnome.org/GNOME/glib/issues/1923
Signed-off-by: Simon McVittie <smcv@collabora.com>
Whitelist a safe set of characters for use in header guards instead of
maintaining a (growing) blacklist.
The whitelist is intentionally short since reading up on all
peculiarities of the C and C++ standard for identifiers is not my idea
of fun. :)
Fixes#1379
