The value returned when generating a collation key is an opaque binary
blob that is only meant to be used for byte-wise comparisons; we should
not imply it's a nul-terminated, UTF-8 string.
This is especially true for language bindings that try to convert C
strings returned by GLib into UTF-8 encoded strings.
Ideally, the collation functions should return a byte array, but the
closest thing we have is the OS native encoding type that we use for
paths and environment variables.
See: https://github.com/gtk-rs/gtk-rs-core/issues/1504
When the child process is going to exit on error after fork() but before
exec(), let's close the child_err_report_fd. The practical value of this
is to placate valgrind --track-fds=yes.
The changes made in commit bc59e28bf6
(issue #3399) fixed introspection of the GThread API. However, they
introduced a trampoline in every threading function. So with those
changes applied, the disassembly of `g_mutex_lock()` (for example) was:
```
0x7ffff7f038b0 <g_mutex_lock> jmp 0x7ffff7f2f440 <g_mutex_lock_impl>
0x7ffff7f038b5 data16 cs nopw 0x0(%rax,%rax,1)
```
i.e. It jumps straight to the `_impl` function, even with an optimised
build. Since `g_mutex_lock()` (and various other GThread functions) are
frequently run hot paths, this additional `jmp` to a function which has
ended up in a different code page is a slowdown which we’d rather avoid.
So, this commit reworks things to define all the `_impl` functions as
`G_ALWAYS_INLINE static inline` (which typically expands to
`__attribute__((__always_inline__)) static inline`), and to move them
into the same compilation unit as `gthread.c` so that they can be
inlined without the need for link-time optimisation to be enabled.
It makes the code a little less readable, but not much worse than what
commit bc59e28bf6 already did. And perhaps
the addition of the `inline` decorations to all the `_impl` functions
will make it a bit clearer what their intended purpose is
(platform-specific implementations).
After applying this commit, the disassembly of `g_mutex_lock()`
successfully contains the inlining for me:
```
=> 0x00007ffff7f03d80 <+0>: xor %eax,%eax
0x00007ffff7f03d82 <+2>: mov $0x1,%edx
0x00007ffff7f03d87 <+7>: lock cmpxchg %edx,(%rdi)
0x00007ffff7f03d8b <+11>: jne 0x7ffff7f03d8e <g_mutex_lock+14>
0x00007ffff7f03d8d <+13>: ret
0x00007ffff7f03d8e <+14>: jmp 0x7ffff7f03610 <g_mutex_lock_slowpath>
```
I considered making a similar change to the other APIs touched in #3399
(GContentType, GAppInfo, GSpawn), but they are all much less performance
critical, so it’s probably not worth making their code more complex for
that sake.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3417
And size it to `sysconf (_SC_MINSIGSTKSZ)`, if defined.
This might fix the sigaltstack test on muslc, as suggested by Markus
Wichmann (https://www.openwall.com/lists/musl/2024/05/30/2) and Rich Felker
(https://www.openwall.com/lists/musl/2024/05/29/7) on the musl mailing
list.
The thinking is that the CI machine might have a huge register file
(AVX512 or some other large extension) which doesn’t fit in `MINSIGSTKSZ`.
By sizing the alternate stack to `sysconf (_SC_MINSIGSTKSZ)` we should
be able to avoid that.
Moving it onto the heap should avoid any potential complications or bugs
from having one stack embedded within another.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3315
This function type isn't only used by g_hash_table_foreach_remove(), and
what happens to the data when we return TRUE depends on the calling
function.
Includes a port to modern gi-docgen syntax by Emmanuele Bassi.
Signed-off-by: Adrien Plazas <adrien.plazas@codethink.co.uk>
GHashTable optimizes for the "set" case, where key and value are the same.
See g_hash_table_add().
A user cannot see from outside, whether a GHashTable internally is a set
and shares the keys and values array. Adding one key/value pair with
differing key and value, will expand the GHashTable.
In all other cases, the GHashTable API hides this implementation detail
correctly. Except with g_hash_table_steal_extended(), when stealing both the
key and the value.
Fix that. This bug fix is obviously a change in behavior. In practice,
it's unlikely that somebody would notice, because GHashTable contains
opaque pointers and the user must know what the keys/values are and
be aware of their ownership semantics when stealing them. That means,
the change in behavior only affects instances that are internally a set,
of what the user most likely is aware and fills the table with
g_hash_table_add(). Such a user would not steal both the key and
values at the same time. Even if they do, then previously stealing the
value was pointless and would not give them what they wanted. It would
not have meaningfully worked, and since nobody reported a bug about this
yet, it's unlikely somebody noticed.
The more problematic case when the user exhibits the bug is when the
dictionary is unexpected a set internally. Imagine a mapping from numbers
to numbers (e.g. a permutation). If "unexpectedly" the dictionary contains
the identity permutation, steal-extended gives always NULL for the target
number.
The example is far fetched. In practice, it's unlikely that somebody is
gonna notice either way. That is not an argument for fixing anything.
The argument for fixing this, is that the bug breaks the illusion that
the set is only an internal optimization. That is ugly and inconsistent.
Some g++ versions issue an unused-result warning for the g_string_free() macro:
error: ignoring return value of 'gchar* g_string_free_and_steal(GString*)',
declared with attribute warn_unused_result [-Werror=unused-result]
g_string_free(s, TRUE);
This occurs with gcc 6.x / 7.1 / 7.2, and it is fixed in gcc 7.3.
This fixes the annoations for g_mapped_file_get_contents() which looks
like it might transfer ownership (due to being a char*) but does not as
we're pointing into the mmap() region.
The issue of meson 60 have been resolved for some time now, so we can
just use newer TAP syntax safely.
Revert "gtestutils: Use TAP 13 comments syntax for subtests"
This reverts commit e8725407bcd35c1fa8fed92250edf080d5542b3c.
Closes: #2885
Now that we've switched to `gi-docgen`, let's make sure our docs are
getting updated. This commit fixes most of the previous gtk-doc
references so that they now follow gi-docgen syntax.
Some exceptions are functions or types that are referenced, but are
generated by a higher level layer like `Gio`, `GObject` or `Gtk`.
Some callers of `g_ascii_strtoull()` and similar functions assume that
they can use this pattern, similar to what they might do for
Standard C `strtoull()`:
errno = 0;
result = g_ascii_strtoull (nptr, endptr, base);
saved_errno = errno;
if (saved_errno != 0)
g_printerr ("error parsing %s\n", nptr);
This is based on the fact that it is non-trivial to tell whether
`strtoull()` and related functions succeeded (in which case the value
of `errno` is unspecified) or failed (in which case `errno` is valid).
For example, POSIX `strtoul(3)` suggests this pattern:
> Since 0, `ULONG_MAX`, and `ULLONG_MAX` are returned on error and are
> also valid returns on success, an application wishing to check for
> error situations should set `errno` to 0, then call `strtoul()` or
> `strtoull()`, then check `errno`.
However, `g_ascii_strtoull()` does not *only* call a function resembling
`strtoull()` (`strtoull_l()` or its reimplementation
`g_parse_long_long()`): it also calls `get_C_locale()`, which wraps
`newlocale()`. Even if `newlocale()` succeeds (which in practice we
expect and assume that it will), it is valid for it to clobber `errno`.
For example, it might attempt to open a file that only conditionally
exists, which would leave `errno` set to `ENOENT`.
This is difficult to reproduce in practice: I encountered what I
believe to be this bug when compiling GLib-based software for i386 in a
Debian 12 derivative via an Open Build Service instance, but I could
not reproduce the bug in a similar chroot environment locally, and I
also could not reproduce the bug when compiling for x86_64 or for a
Debian 10, 11 or 13 derivative on the same Open Build Service instance.
It also cannot be reproduced via the GTest framework, because
`g_test_init()` indirectly calls `g_ascii_strtoull()`, resulting in
the call to `newlocale()` already having happened by the time we enter
test code.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3418
Signed-off-by: Simon McVittie <smcv@collabora.com>
Move various doc/introspection comments from `gthread-posix.c` (which is
platform-specific) to `gthread.c` (which is not). Having the
introspection annotations and doc comments in a platform-independent
file means that they are seen by the build process on all platforms, and
we don’t end up with unintrospectable APIs on some platforms, or
platform-specific annotation differences.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
Using G_STATIC_ASSERT in headers which are introspected currently
requires guarding them behind `#ifndef __GI_SCANNER__` which is really
annoying. We can just define the macros to be noops in a way that the
scanner doesn't trip over them.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
They are guarded for the GI Scanner right now even though they should be
fine to expose and they are used in macros that are not guarded for the
GI Scanner.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
* Create a dark-mode variant of each traversal diagram, with the
traversal path colorized `--primary` blue, instead of the original
black.
* Apply the same colorizations to the light-mode diagrams, but
using the light-theme `--primary` blue.
* Add SPDX license/copyright comments to all eight SVG files.
* Add new files to documentation configs in `glib.toml.in`.
* Update documentation comment in `gnode.c` to embed both color
variants via picture tags, instead of markdown image embeds.
* Add alt text to all four images.
* Add additional blank lines to documentation comment, so that
a. First item in bulleted list does not get folded into
preceding intro paragraph
b. Intro paragraph and diagrams are not part of first paragraph
in documentation. (This also gets them out of the top-level
table-of-contents/index list, where they previously appeared
in full.)
* (Accidental change I didn't realize I was making): Convert line
endings in breadth-first diagram from CRLF to LF.
This file doesn’t contain any real implementation, it just call the
`impl` functions from the platform-specific files
`gspawn-{posix,win32}.c`.
It serves as a location for the doc comments, introspection annotations
and API preconditions, and will be built on every platform. In
particular, this means that we get consistent GIR output for the
`g_spawn_*()` APIs regardless of whether GLib was built on Linux or
Windows.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
This is the first step towards separating the API documentation and
introspection annotations from the platform-specific implementation, so
we can guarantee that the APIs make it into `GLib-2.0.gir` regardless of
which platform the GIR is built on.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3399
fb58d55187 added weak linking for ASAN,
skipping it for MinGW because weak symbols are broken there.
The same is true for Cygwin, so skip things there too.
This fixes the following build error under MSYS2:
/usr/lib/gcc/x86_64-pc-msys/13.3.0/../../../../x86_64-pc-msys/bin/ld:
glib/msys-glib-2.0-0.dll.p/gutils.c.o:gutils.c:
(.rdata$.refptr.__lsan_enable[.refptr.__lsan_enable]+0x0): undefined reference to `__lsan_enable'
There are a couple of places in the code which use `isnan()` and have
platform-specific workarounds for it. Unify those, and extend the
workaround to work for msys2-mingw32.
It seems that msys2-mingw32 can’t automatically use `isnan()` in a wider
mode than `float`:
```
In file included from ../glib/gdatetime.c:60:
../glib/gdatetime.c: In function 'g_date_time_new':
../glib/gdatetime.c:1648:14: error: conversion from 'gdouble' {aka 'double'} to 'float' may change value [-Werror=float-conversion]
1648 | isnan (seconds) ||
| ^~~~~~~
cc1.exe: all warnings being treated as errors
```
See: https://gitlab.gnome.org/pwithnall/glib/-/jobs/4022715
Using it in float mode on all platforms should not change behaviour, as
a conversion from `(double) NAN` to `float` should still give `NAN`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
gnulib doesn’t work with it, and if we try and enable it then mingw
versions of `signbit()` start causing problems.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
While an index greater than `G_MAXINT` can’t be passed to
`g_ptr_array_insert()`, `-1` can be — and if that’s done with an array
which has more than `G_MAXINT` elements in it, the new element will be
inserted part-way through the array rather than being appended.
Spotted by building with `-Wsign-conversion`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
The latter only accepts a `gint` as the number of elements in the array,
which means that its use in `GArray` (and related array implementations)
truncates at least half the potential array size.
So, introduce a replacement for it which uses `size_t` for the number of
elements. This is inline with what `qsort()` (or `qsort_r()`) actually
does. Unfortunately we can’t directly use `qsort_r()` because it’s not
guaranteed to be a stable sort.
This fixes some `-Wsign-conversion` warnings (when building GLib with
that enabled).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This makes no functional changes, but does avoid a warning from
`-Wfloat-conversion` due to implicitly switching from `guint64` to
`gdouble` and then back to `guint64`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This avoids some false positive warnings from `-Wfloat-conversion`.
The code in `gtestutils.c` is a bit odd: it uses an array of `long
double` elements, with specific indices of that array storing specific
meaningful numbers, each of which has a type which is representable as a
`long double`, but which actually isn’t.
This is a prime candidate for refactoring to not use such a type-unsafe
API where everything is marshalled through `long double`. Unfortunately,
the array is declared in `GTestLogMsg`, which is defined in the public
`gtestutils.h` header, so we can’t change it. Boo.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
If we enable `-Wfloat-conversion`, these warn about a possible loss of
precision due to an implicit conversion from `double` to some other
numeric type.
The warning is correct: there is a possible loss of precision here. In
these instances, we don’t care, as the floating point arithmetic is
being done to do some imprecise scaling or imprecise timing. A loss of
precision is not a problem.
So, add an explicit cast to squash the warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
Commit 9dad94e7q ensured `test_data` is freed when a test is skipped,
but didn't ensure that when a whole test suite is skipped.
We are assuming the ownership of `test_data` is passed to GTestCase
with `g_test_add_data_func_full()` so free `test_data` always when
freeing a test case.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
gmacros.h casts functions to GDestroyNotify, which prevents enabling the
following hardening options in applications: -fsanitize=address
-fsanitize=cfi-icall (without -fsanitize-cfi-icall-generalize-pointers),
and -Wcast-function-type-strict.
Define another inline function that warps the original function into
GDestroyNotify.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
We have required C99 for a while; in the meantime, most C toolchains
have moved on to C11 or later as the default C standard.
We still allow for C99 toolchains, but in the future we are going to
require a C11 toolchain to build and use GLib.
Some of these are properties of a Standard C or POSIX platform that
are true by definition and checked for completeness (for example intptr_t
is defined to be signed, and uintptr_t unsigned), while others are
checking that GLib's type detection has been done correctly.
Signed-off-by: Simon McVittie <smcv@debian.org>
Neither the new nftw()-based rm_rf() implementation, nor the fallback
implementation, should fail the test if there is an error during cleanup
of the directory tree. And the output on stderr that the nftw()-based
implementation emits should not interfere with Meson parsing the TAP
stream on stdout.
The test is run in a subprocess so that we can clean up after ourselves.
Previously, when cleaning up the temporary directory tree created by
passing G_TEST_OPTION_ISOLATE_DIRS, any symbolic links in that tree
would be followed recursively. If the test case has created a symbolic
link in its temporary directory to a directory outside that tree, this
could lead to unexpected data loss; in particular, if the test case
author has (unwisely) created a symbolic link to /, they could lose all
data on the system.
On systems that have the ftw.h header, replace the current rm_rf()
implementation with one that uses nftw() to perform a depth-first
traversal (FTW_DEPTH) without following symbolic links (FTW_PHYS), and
without crossing mount points (FTW_MOUNT) in case a test has mounted
some other filesystem in the temporary directory.
The callback logs any error to the standard error stream, but returns 0
rather than -1 to allow nftw() to keep walking the tree rather than
terminating immediately. Suppose we are trying to clean up the following
tree:
tmpdir/
a/
f/ (directory not readable for some reason)
g/
p
b/
c
d
Since tmpdir/a/f is not readable, we can expect to fail to delete
tmpdir/a/f, tmpdir/a and tmpdir; but it is preferable to (attempt) to
delete the rest of the tree rather than failing outright. The cost is
that three errors will be logged (for tmpdir/a/f, tmpdir/a and tmpdir).
nftw() is part of POSIX.1-2001, SUSv1, and glibc ≥ 2.1, so should be
available on effectively every platform except Windows. (And Windows
does not enable symbolic links by default so the developer error is less
likely to occur there.)
The macOS ftw(3) manpage says:
> These functions are provided for compatibility with legacy code. New
> code should use the fts(3) functions.
fts(3) does not seem to be part of any standard, but it does seem to be
equally widely supported. The Linux manpages do not indicate that
nftw() is deprecated.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3290
Do not try to inject the C standard into `c_args`: Meson already
generates a compiler command line with the appropriate C standard, and
adding another one into it at a random position is either potentially
undefined behaviour, or it's going to break the build because the
compiler does not accept more than one switch.
Meson has an `override_options` argument for the executable() object,
and we are already using it in places.
GVariant Text Format section on bytestrings links to `g_strcompress`
but what it does was only briefly described in the header file,
which is not visible in the gi-docgen-built reference. To really
find out one would have to guess to continue through the rabbit hole
to `g_strescape`.
Let’s merge the description from the header and elaborate on it a bit.
Saying that it inserts a backslash before special character is incorrect
for anything but a double quote and backslash itself. Instead, it replaces
the special characters with a C escape sequence.
Let’s fix that and also make it less C focused by using Unicode names
of the characters instead of assuming everyone knows C escape sequences
by heart.
GCC 14 now emits this warning with the tests:
```
In file included from ../glib/gthread.h:34,
from ../glib/gasyncqueue.h:34,
from ../glib/glib.h:34,
from ../glib/tests/atomic.c:14:
../glib/tests/atomic.c: In function 'test_types':
../glib/gatomic.h:140:5: error: argument 2 of '__atomic_store' discards 'volatile' qualifier [-Werror=discarded-qualifiers]
140 | __atomic_store (gaps_temp_atomic, &gaps_temp_newval, __ATOMIC_SEQ_CST); \
| ^~~~~~~~~~~~~~
../glib/tests/atomic.c:139:3: note: in expansion of macro 'g_atomic_pointer_set'
139 | g_atomic_pointer_set (&vp_str_vol, NULL);
| ^~~~~~~~~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
```
I can’t think of a way to cast around this in the definition of
`g_atomic_pointer_set()` without making the behaviour worse (less type
safe) for modern non-volatile atomic variables.
We would like to strongly nudge users of GLib away from declaring atomic
variables as `volatile`, so letting another compiler warning be emitted
when they do is not the end of the world. As long as it doesn’t stop old
code compiling (without `-Werror`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When running the alternate stack tests under valgrind the stack memory
gets corrupted that we've initialized gets somehow corrupted and this
causes a read-error while reading the stack memory area.
No matter if we use instead malloc-allocated or mmap'ed memory areas,
the result is always the same: a memory error while reading it.
Reading byte 2645
Reading byte 2646
Reading byte 2647
Reading byte 2648
==46100== Invalid read of size 1
Now this memory is definitely stack-allocated and unless the valgrind
stack gets corrupted, there's no way it could have been removed.
I quite trust that this is some valgrind problem only though since no
other memory analyzer I've tried (memory sanitizer mostly) has
highlighted any issue with this.
As per this, since the main point of the test was just checking if
signals are delivered properly even when using an alternate stack, I
think that we can just safely run a simpler version of the test when
running under valgrind. This implies assuming that sigaltstack()
does what is supposed to do, without us double-checking it, but I guess
we can trust that (especially because we're still testing it when not
using valgrind).
Closes: #3337
Some architecture such as sparc and some flavors of arm needs -latomic
to avoid the following build failure:
gthread-posix.c:(.text+0xda8): undefined reference to `__atomic_compare_exchange_4'
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This fixes commit 057f0fcbfb. I didn’t
notice that `tmp` is an array of strings, not an array of chars, and
somehow my compiler didn’t warn. Seems only the macOS CI job is spotting
the problem here.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than returning through `G_VARIANT_TYPE`, which scan-build doesn’t
seem to fully understand ownership transfers through, just return `new`
directly, and do the `is_valid()` check separately.
The new code is equivalent to the old code, but squashes a scan-build
false positive around leaking `dest`. (See also: the previous commit.)
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
This introduces no functional changes. Switch from incrementing a
pointer to incrementing a counter and using array indexing.
This squashes a scan-build false positive, where it can’t choose which
of `dest` and `new` ‘own’ the newly allocated memory, so it kind of
assumes both do, and then warns there’s a potential leak of `dest` when
the function returns. In actual fact, ownership of the memory is
returned via `new`.
Partly this might be masked through use of the `G_VARIANT_TYPE` macro,
which the following commit will address.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Otherwise scan-build thinks there could be `NULL` pointer dereference of
the `tz`. (There can’t be, it’s a false positive. 🤫)
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks there’s a potential `NULL` pointer dereference of some
of the members of `msg->strings`, because it doesn’t know about the
implicit invariant that the length of `msg->strings` is
`msg->n_strings`.
Ideally we want an assertion like `g_assert (g_strv_length
(msg->strings) == msg->n_strings)`, but that’s not very performant, so
just settle for a non-`NULL` assertion on each loop iteration to give
scan-build the hint it needs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
This helps out scan-build, which otherwise thinks there could be a
`NULL` pointer dereference.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that `tmp` can be dereferenced before it’s all been
assigned to. I don’t think that’s the case, because the number of
elements in it which have been assigned to is tracked as `i`. But static
analysers find that kind of state tracking hard to reason about, so
let’s just zero-initialise the array to simplify things.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
