The define for g_utf8_next_char(p) includes a not needed final cast to
(char *). In fact, this cast has the adverse effect of causing a warning
if p is a (const char *) with gcc/clang compiler option -Wcast-qual.
So lets remove the not needed cast and add option -Werror=cast-qual
to glib/tests/utf8-pointer.c which uses g_utf8_next_char().
Now utf8-pointer.c compiles also with compiler option -Werror=cast-qual
and passes all tests.
It's well known that memset may be optimized out by compilers and this
is one of these cases that freebsd CI highlighted.
To prevent this to happen we should use memset_explicit() but that's C23, so
till we don't support that, let's re-implement that ourself
making the compiler not to optimize our memset's.
In theory we could just rely on C11's memset_s, but that's not working
either in freebsd.
In other unix implementations other than linux, sigaltstack can't use a
NULL pointer for old_stack, so let's use SS_DISABLE instead to disable
the alternate stack.
Co-Authored-By: Marco Trevisan <mail@3v1n0.net>
Some applications, toolkits or languages may define an alternative stack
to use for traces. This is for example the case of go.
So, in case an application defines an alternate signal stack, GLib should
use that instead of the default one to receive signals otherwise it may
break the application expectations and write where it's not allowed to.
When piecewise validating the offset table for a variable sized array,
it’s possible that the offset table (`offsets.array`) won’t actually
have been set by `gvs_variable_sized_array_get_frame_offsets()` iff the
serialised `GVariant` is not in normal form.
Add an additional check to guard against this. This will result in an
empty child variant being returned, as with other error handling paths
in `gvs_variable_sized_array_get_child()`.
This is a true positive spotted by scan-build. Thanks, scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Spotted by scan-build, an actual true positive result from it, and a
fiendish one too.
If any of the calls to `dupfd_cloexec()` (except the final one) fail,
the remainder of the `duped_source_fds` array would have been left
uninitialised.
The code in `out_close_fds` would have then called `g_clear_fd()` on an
uninitialised FD, with unpredictable results.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
This reverts commit 280c8d41fb.
It breaks the unit tests on macOS (see #3314) and no fix has been
forthcoming.
The alternate stack changes can be resubmitted once they include a
working unit test on macOS, as evidently its treatment of alternate
stacks differs from that on Linux, and hence needs testing.
Helps: #3314
Some applications, toolkits or languages may define an alternative stack
to use for traces. This is for example the case of go.
So, in case an application defines an alternate signal stack, GLib should
use that instead of the default one to receive signals otherwise it may
break the application expectations and write where it's not allowed to.
The python interpreter found by `/usr/bin/env python3` is not
necessarily the same installation as the one that's found by meson's
`pymod.find_installation('python')`. This means that even though meson
is checking that the python installation it found includes the
'packaging' module, the scripts might not have access to that module
when run.
For distribution packaging, it's usually desirable to have python script
interpreters be fully specified paths, rather than use `/usr/bin/env`,
to ensure the scripts run using the expected python installation (i.e.
the one where the python 'packaging' dependency is installed).
The easiest way to fix this is to set the script interpreter to the
`full_path()` of the python interpreter found by meson. The specific
python interpreter that will be used can be selected through the use of
a meson machine file by overriding the "python" program. Many
distributions already have this set up using meson packaging helpers.
This fixes an issue with the number getting very big due to
CPU_ISSET not returning exactly 0 or 1.
This also fixes scenarios where there are holes in the CPU
set. E.g. for a simple run like `taskset --cpu-list 1,2,4 ...`
the old code would return 2 instead of 3, due to iterating
until `ncores` (which is 3) and therefore not accounting for
CPUs further in the set.
Ref https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3784
The dataset tests are using a subprocess to catch possible deadlocks
within the `test_datalist_clear()` test. However, that’s causing
occasional spurious test failures on the slower CI runners, where the
subprocess can take longer than 500ms to run due to the machine being
overloaded.
Remove the subprocess from the test, and allow the test to deadlock if
it fails. The Meson test harness has a timeout for catching things like
this.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For those projects that cannot use `g_autoptr()`, GStrvBuilder's end
plus unref is not really convenient.
We can crib the "unref to data type" model from GBytes, and have an
additional unref function that also returns the just built GStrv.
If our GPollFunc is set to g_poll() then we can optionally use a poll()
alternative with higher precision. ppoll() provides poll() equivalence
but with timeouts in nanoseconds.
With more precise polling timouts, frame clocks and other timing sensitive
APIs are not restricted to a minimum of 1 millisecond timeout.
This gets access to the timeout as microseconds up until we are about to
enter the GPollFunc. This is useful so that alternative means may be used
to poll with more precision for timeout.
This was erroring on recent GCC because `struct heap_dict` is smaller than
the publicly provided size (guintptr[16]) in the header for GVariantDict.
Port to use `g_malloc()` directly, and use a static assertion to ensure
we’re allocating the larger of the two struct sizes.
It may not be obvious, but the moment unlock is called, the locker
instance may be destroyed.
See g_object_unref(), which calls toggle_refs_check_and_ref_or_deref().
It will check for toggle references while dropping the ref count from 2
to 1. It must decrement the ref count while holding the lock, but it
also must still unlock afterwards.
Note that the locker instance is on the object itself. Once we decrement
the ref count we give up our reference and another thread may race
against destroying the object. We thus must not touch object anymore.
How can we then still unlock?
This works correctly because:
- unlock operations must not touch the locker instance after unlocking.
- assume that another thread races g_object_unref() to destroy the
object, while we are about to call object_bit_unlock() in
toggle_refs_check_and_ref_or_deref(). Then that other thread will also
need to acquire the same lock (during g_object_notify_queue_freeze()).
It thus is blocked to destroy the object.
Add code comments about that.
These unfortunately have `gchar*` return types rather than `const
gchar*`. This is a historical artifact which we can’t change: while
adding `const` would only be an API break and not an ABI break, it would
cause all sorts of C++ code which uses GLib to emit new cast warnings
(similarly, C code with const correctness compiler warnings enabled
would do the same).
The incorrect return type causes the GIR scanner to (reasonably) assume
the return value is allocated, which is wrong.
Fix that by explicitly adding `(transfer none)`.
Also add an explicit `(nullable)` because all three functions are.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3286
Partially because the use of `G_GSIZE_MODIFIER` breaks translatable
string extraction (issue #3271) and partially because `g_format_size()`
produces more human-readable results anyway.
Prior to commit cf5e371c67 the code was using `%lu`, so this is a fairly
new issue.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3271
PCRE2 10.43 has now introduced support for variable-length lookbehind,
so these tests now fail if GLib is built against PCRE2 10.43 or higher.
See
e8db6fa713/ChangeLog (L94).
Rather than making the tests conditional on the version of PCRE2 in use,
just remove them. They are mostly testing the PCRE2 code rather than
any code in GLib, so don’t have much value.
This should fix CI runs on msys2-mingw32, which updated to PCRE2 10.43 2
days ago.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It's helpful for the assertion message to say what we were expecting and
what we actually got. It's also useful to have g_test_message()
diagnostics to indicate how far into the test we were.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we didn't test these at all, which made it hard to determine
whether %Ec, %EC had appropriate output on platforms where era-based
dates are unsupported. Now we do, and we can observe that on platforms
with no support for era-based dates, %c matches %Ec and %C matches %EC,
as desired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I can't read Japanese, but these match the output of:
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%c' | iconv -f eucjp -t UTF-8
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%C' | iconv -f eucjp -t UTF-8
which seem like a reasonable thing to use as a reference.
According to Google Translate, 平成 refers to the Heisei era, which was
current during 2009, and seems unreasonable to expect as output on a
platform where era-based dates are unsupported.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3252
Signed-off-by: Simon McVittie <smcv@collabora.com>
