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>
Introduce support for terminals executing commands without an option,
i.e., the command is passed directly as argument to the terminal emulator.
This is needed for xdg-terminal-exec.
Get rid of multiple conditionals branch by using a loop and storing the
options needed by particular terminal emulators directly in an array.
Remove intermediate variable term_argv as we don't need it.
Advantages:
- simpler logic, less branching
- the terminal emulator list is more readable, by virtue of being
condensed in one array. Launch options to execute a terminal program
are also more explicitly specified
- the logic become independent from the order
- one less allocation
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.
The function adjusting private struct size to private struct offset
should be `g_type_class_adjust_private_offset`, instead of the
previously misspelled `g_type_class_add_instance_private` in comment.
Fixes#2791
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>
