Note that for alignments we should actually use size_t, but this would
imply some refactors since this value can be acually set to -1 in our
implementation.
So we use gssize for now, that at least on gcc is defined.
We are using various indexes types, but not always using the correct
sign or size, so let's adapt this to ensure we're consistent with the
values we're comparing with.
Even though we expose member access as size_t, a GI info blob can
typically just access to an a number of values that is never bigger
than uint16_t, as that's how the typelib is defined (cfr. typelib
internal header blob sizes and n_* elements).
So let's avoid this to happen by adding a check.
We used to use unsigned values, while they should be big enough to old
the data we're handling here, it's cleaner and clearer if we use size_t
as type for such values, as it makes straight forward to understand what
a value should contain. It also makes these values more future proof.
We just do a safe s/gsize/size_t/ replacement here without doing any
changes to places in which different size of size_t and gsize may be
actually different and create troubles.
This also fixes the build for AArch64 since cmph_uint32 is not big
enough to hold a pointer there. I found this while building for CHERI
since the compiler errors there when casting from a non-inptr_t integer.
This also fixes warnings when building for AArch64 with clang.
This doesn't appear to work reliably on s390x and ppc64, returning
the results that were expected without %E or intermittently crashing.
It seems that on little-endian 64-bit, the intptr_t returned by the
undocumented _NL_TIME_ERA_NUM_ENTRIES correctly has the number of entries
in its low-order half (at the time of writing, 0x0000'0000'0000'000b for
Japan), but on big-endian 64-bit, it has the number of entries in its
high-order half instead (for example 0x0000'000b'0000'0000 for Japan),
with the low-order half being all-zero or possibly uninitialized.
Making this reliable will require some sort of defined API from glibc.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/3225
Bug-Debian: https://bugs.debian.org/1060735
Signed-off-by: Simon McVittie <smcv@collabora.com>
As seen in [CI](https://gitlab.gnome.org/GNOME/glib/-/jobs/3436216):
```
==13767== 144 (40 direct, 104 indirect) bytes in 1 blocks are definitely lost in loss record 528 of 562
==13767== at 0x4A18B2C: g_type_create_instance (gtype.c:1928)
==13767== by 0x49F92FF: g_object_new_internal (gobject.c:2235)
==13767== by 0x49FA247: g_object_new_valist (gobject.c:2574)
==13767== by 0x49F8D81: g_object_new (gobject.c:2047)
==13767== by 0x4AE2337: g_inet_socket_address_new (ginetsocketaddress.c:387)
==13767== by 0x4B1DB94: g_socket_address_new_from_native (gsocketaddress.c:230)
==13767== by 0x4B16CC2: g_socket_get_local_address (gsocket.c:2071)
==13767== by 0x40E102: test_receive_bytes_from (socket.c:2469)
==13767== by 0x4901E78: test_case_run (gtestutils.c:2974)
==13767== by 0x49022B2: g_test_run_suite_internal (gtestutils.c:3069)
==13767== by 0x490241A: g_test_run_suite_internal (gtestutils.c:3088)
==13767== by 0x4902690: g_test_run_suite (gtestutils.c:3168)
==13767== by 0x4900C8F: g_test_run (gtestutils.c:2275)
==13767== by 0x40EE8A: main (socket.c:2614)
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3220
We only care about the introspection data for documentation purposes;
the GStaticMutex and GStaticRecMutex types are long since deprecated,
and they cannot be used from language bindings anyway, so their size is
immaterial.
Fixes: #3222
There are several reasons why we might not be able to do the test setup
for --external-data: non-Linux platform, missing ld or objcopy,
objcopy doesn't support --add-symbol, or the CPU family is MIPS
(on which cc -r does not necessarily emit the specific MIPS ABI flavour
that we are targeting, for example different functionality levels or
different NaN encodings).
If we can't link in the test data, then obviously this test is not going
to pass. It was already skipped on non-Linux, but not on platforms that
hit one of the other reasons for the test setup to fail.
In particular, this test failed on Debian mips64el since commit 81059169,
which stopped linking the necessary resource on MIPS platforms, but
continued to assert that the resource is present at runtime.
Fixes: 81059169 "GIO/tests: skip test_resources_binary on MIPS platform"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3226
Signed-off-by: Simon McVittie <smcv@debian.org>
