Otherwise clang would complain:
../glib/tests/strfuncs.c:2603:32: warning: result of comparison
against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
g_assert_true ((gpointer)str != (gpointer)"");
^ ~~~~~~~~~~~~
../glib/gtestutils.h:187:59: note: expanded from macro 'g_assert_true'
if G_LIKELY (expr) ; else \
^~~~
../glib/gmacros.h:1186:59: note: expanded from macro 'G_LIKELY'
#define G_LIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 1))
^~~~
../glib/gmacros.h:1180:8: note: expanded from macro '_G_BOOLEAN_EXPR'
if (expr)
It’s entirely possible that `g_file_read_link()` will return a relative
path. Mention that in the documentation, and include a short example of
how to make the path absolute for further computation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The changes in 6265b2e6f7 to reject weird
`/etc/localtime` configurations where `/etc/localtime` links to another
symlink did not consider the case where the target of `/etc/localtime`
is a *relative* path. They only considered the case where the target is
absolute.
Relative paths are permissible in all symlinks. On my Fedora 36 system,
`/etc/localtime`’s target is `../usr/share/zoneinfo/Europe/London`.
Fix the check for toolbx by resolving relative paths before calling
`g_lstat()` on them.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Standard C specifically does not guarantee this, and it's untrue on
CHERI architectures (which have 128-bit pointers into a 64-bit
address space, with the remaining bits used for a capability-like
mechanism).
Signed-off-by: Simon McVittie <smcv@collabora.com>
When collecting varargs, ignore the NOCOPY_CONTENTS
flag for variants. That is what our docs advice for
refcounted types, and it fixes a regression that
was inadvertendly introduced when we stopped doing
some extra GValue copies.
Includes a test case by Philip Withnall.
Fixes: #2774
Dereferencing a pointer to a 64-bit object as though it was a 32-bit
object is the same as taking the least significant 32 bits on a
little-endian machine, but on a big-endian machine it is the same as
taking the *most* significant 32 bits, which would result in these hash
functions always hashing to zero. The /hash/int64/collisions and
/hash/double/collisions test-cases in glib/tests/hash.c detect this
and fail.
Instead, fetch the whole 64-bit quantity and do the bit-manipulation
to xor the more significant half with the less significant half in an
architecture-neutral way.
Fixes: dd1f4f70 "Optimize g_double_hash implementation"
Fixes: c1af4b2b "Optional optimization for `g_int64_hash`"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2787
Signed-off-by: Simon McVittie <smcv@collabora.com>
This implements https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/350
for GDBus's server implementation.
Abstract sockets belong to the network namespace instead of the mount
namespace. As a result, mount namespace-based sandboxes (e.g. Flatpak)
cannot restrict access to abstract sockets (and therefore GDBus's
unix:tmpdir= server addresses), at least for applications with network
access permission, which may result in sandbox escapes unless the
application running the GDBus server explicitly check that the connecting
process is not in a sandbox. As of the time of writing, no known
applications using GDBusServer does this.
Fix this by always using non-abstract sockets for unix:tmpdir=, which is
allowed by the DBus specification.
Previously it was marked as failing on macOS, but commit
ed3998b390 seems to have fixed that. yay!
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1392
The access and creation time tests create a file, gets the time in
seconds, then gets the time in microseconds and assumes that the
difference between the two has to be above 0.
As rare as this may be, it can happen:
$ stat g-file-info-test-50A450 -c %y
2021-07-06 18:24:56.000000767 +0100
Change the test to simply assert that the difference not negative to
handle this case.
This is the same fix as 289f8b, but that was just modification time.
Signed-off-by: Ross Burton <ross.burton@arm.com>
g_close() now is async-signal-safe, as long as we don't request a GError
and pass a valid file descriptor.
Update "gspawn.c" to drop its safe_close() function and use
g_close() instead.
g_close() does something useful. It is not trivial to get EINTR handling of
close() right, in a portable manner. g_close() abstracts this.
We should allow glib users to use the function even in async-signal-safe
contexts, at least if the user heeds the caveat about GError and take care
not to fail assertions.
Retry on EINTR is wrong on many OS, including Linux. See the comment
in g_close() why that is.
As we cannot use g_close() after fork, we had safe_close(). This had the
wrong retry loop on EINTR. Drop that.
This was especially problematic since commit 6f46294227 ('gspawn: Don’t
use g_close() in async-signal-safe context'). Before, safe_close() was
only called after fork, where there is only one thread and there is no
concern about a race.
This patch only exists for easier backporting of the bugfix. The code
will be reworked further next.
Fixes: 6f46294227 ('gspawn: Don’t use g_close() in async-signal-safe context')
In recent Clang we may get a build warning as per:
../gio/gtask.c: warning: implicit truncation from 'int' to a
one-bit wide bit-field changes value from 1 to -1
[-Wsingle-bit-bitfield-constant-conversion]
This is because we use gboolean (and thus a signed type) for bit-fields.
Now, this is not an issue in practice for the way we're using them, but
still better to mute such compiler warns in the right way.
