There is usually no reason to use the GLib-specific type names here,
other than consistency. The GLib-specific one-word type names can
sometimes be a little more convenient when generating a family of
function names from macros.
Because these types are simple aliases for a hard-coded standard C type,
there should be no API or ABI issues caused by changing existing code to
use the standard C names: a `char **` can already be used interchangeably
with `gchar **`, and name-mangling for a C++ method that takes an `int`
parameter is equivalent to a `gint` parameter.
Helps: #1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
The gversionmacros.h header is referenced from glib/, so it needs to go
into glib's include directory, not in the top-level alongside glib.h,
glib-object.h, gmodule.h, and glib-unix.h.
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 6265b2e6f70d6f0ec4d16adcdc5f7c53aecf0da4 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>
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>
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 6f46294227f8 ('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: 6f46294227f8 ('gspawn: Don’t use g_close() in async-signal-safe context')
It causes the tests to fail, which suggests some latent FD handling bug
on macOS (but not other platforms).
Unfortunately I’m unable to debug that due to not having access to a
macOS machine, and it’s blocking CI for the rest of the project.
So disable it on macOS for now, until someone with access to a macOS
machine can take a look.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2785
Return `G_VARIANT_PARSE_ERROR_RECURSION` from `g_variant_parse()` if a
typedecl is found within a text-form variant which would cause any part
of the variant to exceed the maximum allowed recursion/nesting depth.
This fixes an oversight when `G_VARIANT_MAX_RECURSION_DEPTH` was
implemented, which allowed typedecls to effectively multiply the size of
an array if `g_variant_parse()` was parsing a text-form variant without
a top-level concrete type specified.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2782
oss-fuzz#49462
At the moment, glib assumes that if /etc/localtime is a symlink,
that it's a symlink to zoneinfo file.
Toolbx containers add an extra layer of indirection though, making
it a symlink to a symlink to a zoneinfo file.
This commit deals with the problem, by performing additional checks
on /etc/localtime and ignoring it if those check fail, falling back
instead to reading /etc/timezone.
The previous text was technically correct, but not very clear what
happens with the ownership of the key/value if it was not returned.
Elaborate on the fact, that the key/value is never destroyed, even if
not requested by the user.
I intuitively expected the function to behave differently, that is, to
destroy the key/value if (and only if) it was not returned. That is,
when the function does not return a pointer, then it would destroy it.
That would seem more consistent to me, where ownership is either
transferred to the caller, or the resource destroyed during the steal.
On the other hand, the existing behaviors is:
- is consistent with g_hash_table_steal() and never destroys key/value.
- behaves the same, regardless whether the key/value was returned.
So the existing behavior may be better.
Just elaborate on that detail in the doc.
An application must keep track of the file descriptors that it
has. Closing an invalid, non-negative file descriptor is usually
a bug, because it indicates somebody messed up the tracking.
On a single threaded application it may be fine, but EBADF is always a bug
in a multi threaded application because another thread might race
reusing the bad file descriptor. With GDBus and other glib API, it is very
common that your application has multiple threads running and this is
in fact a bug.
The assertion failure does not necessarily indicate that the bug
is in the caller. It could have been another part of the application
that wrongly closed the file descriptor.
