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
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
On recent versions of Debian, PST8PDT is part of the tzdata-legacy
package, which is not always installed and might disappear in future.
Successfully tested with and without tzdata-legacy on Debian unstable.
Signed-off-by: Simon McVittie <smcv@debian.org>
Instead of using timestamp 0 as a magic number (in this case interpreted
as 1970-01-01T00:00:00-08:00), calculate a timestamp from a recent
year/month/day in winter, in this case 2024-01-01T00:00:00-08:00.
Similarly, instead of using a timestamp 15 million seconds later
(1970-06-23T15:40:00-07:00), calculate a timestamp from a recent
year/month/day in summer, in this case 2024-07-01T00:00:00-07:00.
Signed-off-by: Simon McVittie <smcv@debian.org>
In newer tzdata, it is an alias for America/Los_Angeles, which has a
slightly different meaning: DST did not exist there before 1883. As a
result, we can no longer hard-code the knowledge that interval 0 is
standard time and interval 1 is summer time, and instead we need to look
up the correct intervals from known timestamps.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3502
Bug-Debian: https://bugs.debian.org/1084190
[smcv: expand commit message, fix whitespace]
Signed-off-by: Simon McVittie <smcv@debian.org>
We need to write a Meson cross-compilation file on the fly here, hence the
additions in test-msvc.bat to set up the paths.
Like the 32-bit VS2019 CI job this is only run manually or weekly.
Why they’re necessary, why we _think_ the optimised implementation of
`g_utf8_validate()` is OK despite what valgrind and asan are telling us,
and how they work.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3493
Commit 760a6f647 rearranged how the lengths are calculated for the test
data and added `escape_data_string()` so they could be printed safely.
Unfortunately there was a miscount in the length of the first test
vector in `test_read_upto()`: there are 31 bytes in the string literal,
plus one nul terminator which is added by the compiler. The quoted
string length was 32 bytes. This should be fine (explicitly including
the nul delimiter), but then `escape_data_string()` adds another byte to
the length because it assumes the nul delimiter has *not* been included
in the count.
Changing the string length from 32 to 31 breaks the tests, as the final
component of the data is then the wrong length, so add an additional
explicit nul byte to the string literal so that it matches the length.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is a follow up to commit e7e5ddd2a. oss-fuzz found a case where
performance was pathologically bad with a long `stop_chars` string.
Since our inner loop in that case was iterating over `stop_chars` and
comparing each of them to `buffer[i]`, we can use `memchr()` the
opposite way round to in commit e7e5ddd2a to speed that up, using
`buffer[i]` as the needle in a `stop_chars` haystack.
From some brief testing, this doesn’t impact on the performance of a
more normal use case of having a short (<10 bytes long) `stop_chars`. I
was slightly concerned that the function call overhead of calling out to
`memchr()` would have an impact there, but apparently not.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372994443
I wish people would stop moving their documentation around without
adding redirects. This is not how the internet is supposed to work.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The existing g-io-module-default-singleton-calloc suppression
seems applicable to definite _g_io_module_get_default_type leaks
seen with Valgrind 3.23.0.
This check is necessary for Solaris & illumos, where 32-bit libelf
is incompatible with large-file mode, which meson forces to be enabled,
but 64-bit libelf works fine.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
For historical reasons, pid_t & mode_t are defined as long instead
of int for 32-bit processes in the Solaris headers, and even though
they are the same size, gcc issues -Wformat headers if you try to
print them with "%d" and "%u" instead of "%ld" & "%lu".
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Previously the build was requesting interfaces matching SUSv1/Unix95,
as implemented in Solaris 2.6 and later. This changes it to try the
most recent version supported, and limits to the versions supported
by OS versions that meson supports. This includes these _XOPEN_SOURCE
versions:
800 (2024): supported by illumos starting in July 2024
700 (2008): supported by Solaris 11.4 & illumos from 2014-2024
600 (2001): supported by Solaris 10-11.3 & illumos prior to 2014
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Like _GNU_SOURCE on glibc, this tells the header to define functions
not included in the requested standards versions. This is needed to
build glib/tests/utils-c-89 with -std=c89 and utils-c-89 with -std=c99
and still be able to call functions like isnan() and realpath().
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The refactoring done by commit 168fd4f2b3
lost the definition of the open_max variable used in the Solaris ifdefs.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The method was correctly returning an error from
`g_data_input_stream_read_line_utf8()` if the line contained invalid
UTF-8, but it wasn’t correctly setting the returned line length to 0.
This could have caused problems if callers were basing subsequent logic
on the length and not the return value nullness or `GError`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372819437
