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
fb58d55187dfe1565d10c0c0ffdbaa85376cf0b8 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.
