Every usage in GLib ensures this but theoretically external code might
pass something else. As this is only meant to be used internally from
GLib, don't support the other case but at least avoid potential out of
bound reads.
The length might be passed explicitly in the field instead, and the
string might not have a NUL-terminator as happens for example when
passed from the Rust bindings.
This might lead to out of bounds reads.
Thanks to Sebastian Wiesner for noticing this.
This fixes commit aac56f1618 — I missed
this while reviewing it, but the unit tests were partially changed to
call the new APIs, without being fully changed. This caused the build to
succeed on Linux, but fail on macOS due to using a deprecated API.
Actually, a better approach for the unit tests would be to consistently
call the *old* APIs, as they all immediately call the new APIs. Then we
get coverage of both old and new for free, at the cost of putting
`G_GNUC_BEGIN_IGNORE_DEPRECATIONS` at the top of the test file.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3492
UnixMountEntry: Deprecate g_unix_mount_* API in favor of g_unix_mount_entry_* API for GUnixMountEntry methods
Closes#3492
See merge request GNOME/glib!4337
This issue arises because the g_unix_mount_* naming convention does not match
the GUnixMountEntry instance type, confusing the introspection generator.
To resolve this, we are deprecating the g_unix_mount_* API functions that take
a GUnixMountEntry parameter and introducing equivalent g_unix_mount_entry_*
functions that correctly associate with the GUnixMountEntry instance. This change
ensures that introspection data correctly treats these as instance methods and
that documentation reflects proper ownership of returned data.
(Some minor tweaks by Philip Withnall.)
Fixes: #3492
It appears not to work, and nobody interested in FreeBSD has picked it
up to investigate yet.
Rather than have a completely broken implementation of
`g_file_query_exists()` on FreeBSD, let’s settle for using the old one.
It’s slightly slower than the new one, but has worked fine for people
for years.
This essentially reverts commit 65ad41d8a4
on FreeBSD. This commit can be reverted when a FreeBSD person
investigates what’s going wrong with the `faccessat()`-based
implementation.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3495
valgrind spotted this one: a read off the end of the `stop_chars` buffer
when `stop_chars_len == -1`, due to the fuzzing test not sticking to the
requirement from `g_data_input_stream_read_upto()` that `stop_chars`
must be nul-terminated if `stop_chars_len < 0`.
This can happen when reading `fuzzing/README.md`, which is done as a
smoketest when the fuzzing tests are run without the fuzzer, as normal
unit tests. In this case, it made smoke.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Just like how commit ad572e7780 added an
ifunc resolver for `g_utf8_validate()`, we also need to add one for
`g_str_is_ascii()`, as it also calls into the c-utf8 SIMD validation
code which causes false-positive buffer read overflow warnings from
valgrind and asan.
I thought about just adding the `strlen()` call into `g_str_is_ascii()`
unconditionally, as a simpler fix, but from a quick
codesearch.debian.net, it appears `g_str_is_ascii()` is used quite
widely, so this would have an unacceptable performance impact.
This should fix the valgrind failures on the `search-utils` test seen
here: https://gitlab.gnome.org/GNOME/glib/-/jobs/4423753.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As suggested by Michael Catanzaro, this should make the return type of
the resolve function a bit easier for people to parse.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It looks like these might get more complex in future, as compilers claim
to support the attribute (`__has_attribute(ifunc)` is true) but then
raise errors at compile time if the target architecture doesn’t support
ifuncs.
For example, see #3511.
This doesn’t fix#3511 (I don’t have time to test on musl right now), but
it should make it easier to update the platform preprocessor conditions
in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3511
This adds various additional tests to cover branches of `gunidecomp.c`
which are not already covered, bringing our branch coverage of that file
up to 100% (if you ignore `g_utf8_normalize()`, which is tested by
`unicode-normalize.c` and I’m counting it separately).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3470
This introduces no functional changes, but allows the test to be easily
extended, in the following commit, to test restricted `result_len`
sizes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`g_assert_false (g_unichar_compose (…) && ch == 0)` will succeed if
`g_unichar_compose()` succeeds and returns a non-zero character (which
it will if it succeeds), so this isn’t really testing what we want it to
test. This regressed in commit ae4eea7a39.
Refactor out the repetitive calls to `g_unichar_compose()` and fix the
boolean checks.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Just to make it a bit easier for people to understand the logic in the
implementation in future, because it took me a while.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See the big comment in the code for details. Essentially, this adds a
new compose table specifically for the transitive closure of ‘either’
codepoints — codepoints which appear as the first codepoint in a
composition pair and as the second point in a composition pair
(potentially, but not necessarily, the same pair); or which appear in a
composition pair with an ‘either’ codepoint.
This new compose table has to be symmetrically indexed, as the
`COMPOSE_INDEX` macro doesn’t differentiate based on codepoint position
(first or second). It’s not possible to achieve that with the main
`compose_array` without making it absolutely huge (it’s currently about
150×40 in size and would have to become at least 150×150 in size). In
contrast, the new `compose_either_array` is currently 15×15.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3470
We’re essentially trying to build a minimal perfect hash function, and
`vals` is the map which represents that function. If we redefine a
member of `vals`, the map is no longer a partial function — one input
value (a Unicode codepoint) has two output values (compose table
indices).
So it’s bad if a member of `vals` gets redefined, and we want to be
notified if that happens.
As it happens, some of the new codepoints in Unicode 16.0 cause these
checks to fail. For example, U+16121 Gurung Khema Vowel Sign U
decomposes to U+1611E U+1611E. This causes `vals{U+1611E}` to be defined
to an index from the `first` map, and then redefined to an index from
the `second` map.
The following few commits will fix this, but let’s get the checks in
first.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Because how these big tables of numbers work is perhaps a bit hard to
figure out, and it would be useful to document the design decisions
involved in it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
All changes mechanically generated with:
```
./tools/update-unicode-data.sh ~/Downloads/UCD 16.0.0
```
using the data from https://www.unicode.org/Public/16.0.0/ucd/UCD.zip.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3470
Manually added from the data in
https://www.unicode.org/Public/16.0.0/ucd/UCD.zip.
The following commit will mechanically update the Unicode tables to use
them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3470
Only one other previous author, and my contribution just now is so
simple as to not be copyrightable.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The time has finally come when Unicode has specified a codepoint above
U+FFFF which has a decomposition: U+16125 GURUNG KHEMA VOWEL SIGN AI, in
Unicode 16 which the following commits will add support for.
So far, we’ve managed to store the reverse-lookup from decomposed pairs
to their composed form using a 16-bit integer. Now we have to switch to
storing the composed form in a 32-bit `gunichar` as U+16125 won’t fit
otherwise.
This introduces no functional changes, but does double the in-memory
size of the `compose_array` table from 9176 bytes to 19932 bytes.
The code which uses this lookup table, in `gunidecomp.c`, was already
implicitly converting the loaded value to a `gunichar`, so needs no
changes.
When we update to Unicode 16, the new `NormalizationTest.txt` file
contains a test which will check that composed codepoints > U+FFFF work.
Specifically, U+11391 TULU-TIGALARI LETTER AU is tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3470
The version of ninja-build in Debian 12 isn't built with large file
support, and therefore is not compatible with filesystems with large
inode numbers. Unfortunately, that includes the overlay mounts used by
Docker.
I've suggested a stable update for this as part of the next Debian 12
point release. Until/unless that happens, we can build our own.
Signed-off-by: Simon McVittie <smcv@debian.org>
This is enough to detect most ILP32-specific issues. We previously
relied on 32-bit Windows to catch those, but the toolchains we're using
have increasingly minimal support for 32-bit Windows.
The combination of fedora-x86_64 and debian-stable-i386 between them
should cover nearly everything that debian-stable-x86_64 does, so demote
debian-stable-x86_64 to be run on a schedule or manually.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3477
Signed-off-by: Simon McVittie <smcv@debian.org>
This is identical to the debian-stable image, except that it uses
packages from the i386 dpkg architecture (i686-linux-gnu) instead of
amd64 (x86_64-linux-gnu). x86_64 Docker hosts with x86_64 kernels can
run i386 Docker images, so we can use our existing CI workers.
Instead of duplicating the content of the Dockerfile, add a layer of
architecture-switching so we can build essentially the same image
from a different base.
Signed-off-by: Simon McVittie <smcv@debian.org>
On AIX, the system poll.h redefines the names of struct members,
for example `#define events reqevents`. This means that accesses
to GPollFD will fail to compile if poll.h was included after
glib/gpoll.h.
We can't simply add `#include <poll.h>` in glib/gpoll.h, because
that wouldn't work on platforms where poll.h doesn't exist, and
GLib supports some platforms in that category.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3500
