__atomic_load_8 and friends do not exist under clang. Use the generic
__atomic_load variant instead that are documented here:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
These have the additional benefit that the exact size of gint (4 bytes)
or gpointer (4 or 8 bytes) no longer have to be checked.
I initially tried `__typeof__(*(atomic)) val;`, but that caused warnings
in Clang (-Wincompatible-pointer-types-discards-qualifiers) when
"atomic" points to a volatile variable. Aside from that, it is
apparently not supported everywhere, see the g_has_typeof macro.
Another reason not to use it are new warnings under Clang, including:
glib/deprecated/gthread-deprecated.c:683:11: warning: incompatible pointer types initializing 'typeof (*(&mutex->mutex.mutex))' (aka 'union _GMutex *') with an expression of type 'GRecMutex *' (aka 'struct _GRecMutex *') [-Wincompatible-pointer-types]
g_atomic_pointer_set (&mutex->mutex.mutex, result);
Hence, cast the atomic variable to gint/gpointer pointers, the size was
already statically asserted so the cast should be safe.
The macros use a (hopefully) rare "gaps_temp" name instead of something
like "val" to avoid an issue with GCC builds:
glib/tests/once.c:123:test_once4: assertion failed (val == "foo"): (NULL == "foo")
Closes#1843
These are here to prevent linker errors, since `gcontenttype.[ch]`
aren’t compiled on Windows or macOS.
The implementations are stubs to be filled out by someone who knows each
platform, at some point in the future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1791
We cannot bump to the latest stable version of Meson, even if it would
make our life easier. We can, though, use the version of Meson shipped
by the next, soon to be released Debian stable.
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
The comment previously said ‘never %NULL’, but it wasn’t clear whether
this meant `(not nullable)` or `(not optional)`. From looking at the
code, it means `(not optional)`.
Clarify things by removing the prose. The annotations themselves should
be clear and explicit enough.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1836
If searching for an element which is smaller than every element in the
array (i.e. the element being searched for is not in the array), the
previous g_array_binary_search() implementation would underflow in the
calculation `right = middle - 1`, and end up trying to dereference an
element way off the right of the array.
Fix that by checking the additions/subtractions before doing them, and
bailing if the bounds are hit. We don’t need to check `middle <
G_MAXUINT`, as `middle` is bounded above by `right`, which is always `<=
_array->len - 1`, and `_array->len <= G_MAXUINT`.
Add some tests for that, and for not-present elements in the middle of
the array. Previously, the tests only checked for not-present elements
which were bigger than every element in the array.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If `right` and `left` are both near `G_MAXUINT`, it’s possible for the
addition to overflow, even if the eventual result would fit in a
`guint`. Avoid that by operating on the difference instead.
The difference is guaranteed to be positive due to the prior `left <=
right` check.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The allocation size was set correctly before, but not the array length,
so the copied array appeared to have zero elements.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
