We can get a "-Wcast-align", if the target type that we cast to ("ct") has a
larger alignment than GTypeInstance.
That can happen on i686 architecture, if the GObject type has larger
alignment than the parent struct (or GObject). Since on i686, embeding
a "long long" or a "long double" in a struct still does not increase
the alignment beyond 4 bytes, this usually only happens when using the
__attribute__() to increase the alignment (or to have a field that has
the alignment increased).
It can happen on x86_64 when having a "long double" field.
The compiler warning is hard to avoid but not very useful, because it purely
operates on the pointer types at compile time. G_TYPE_CHECK_INSTANCE_CAST()
instead asserts (in non-optimized mode) that the pointer really points
to the expected GTypeInstance (and if that's the case, then the alignment
should be suitable already).
This is like in commit ed553e8e30 ('gtype: Eliminate -Wcast-align warnings
with G_TYPE_CHECK_INSTANCE_CAST'). But also fix the optimized code path.
With the unpatched G_TYPE_CHECK_INSTANCE_CAST() macro, the unit test would
now show the problem (with gcc-9.3.1-2.fc30.i686 or
gcc-12.2.1-4.fc37.x86_64):
$ export G_DISABLE_CAST_CHECKS=1
$ export CFLAGS='-Wcast-align=strict'
$ meson build
$ ninja -C build
...
In file included from ../gobject/gobject.h:26,
from ../gobject/gbinding.h:31,
from ../glib/glib-object.h:24,
from ../gobject/tests/objects-refcount1.c:2:
../gobject/tests/objects-refcount1.c: In function ‘my_test_dispose’:
../gobject/gtype.h:2523:42: warning: cast increases required alignment of target type [-Wcast-align]
2523 | # define _G_TYPE_CIC(ip, gt, ct) ((ct*) ip)
| ^
../gobject/gtype.h:517:66: note: in expansion of macro ‘_G_TYPE_CIC’
517 | #define G_TYPE_CHECK_INSTANCE_CAST(instance, g_type, c_type) (_G_TYPE_CIC ((instance), (g_type), c_type))
| ^~~~~~~~~~~
../gobject/tests/objects-refcount1.c:9:37: note: in expansion of macro ‘G_TYPE_CHECK_INSTANCE_CAST’
9 | #define MY_TEST(test) (G_TYPE_CHECK_INSTANCE_CAST ((test), G_TYPE_TEST, GTest))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
../gobject/tests/objects-refcount1.c:96:10: note: in expansion of macro ‘MY_TEST’
96 | test = MY_TEST (object);
| ^~~~~~~
It has always been considered an unsigned value, and we also returned it
straight as int in g_hash_table_size(), but it was actually used as an
int.
So use the same type of g_hash_table_size(). Not using more standard
unsigned not to risk that it may different from the guint typedef.
We eventually need to return them as an array anyways.
Sadly we can't just reuse such memory because each element is a pointer and
not a guchar, but still we can be cheaper in various operations.
Add functions to steal all the keys or values from a ghash (especially
useful when it's used as a set), passing the ownership of then to a
GPtrArray container that preserves the destroy notify functions.
GPtrArray's are faster than lists and provide more flexibility, so add
APIs to get hash keys and values using these containers too.
Given that we know the size at array initialization we can optimize the
allocation quite a bit, making it faster than the API using GList both at
creation time and for consumers.
GArray's g_array_append_val(), g_array_prened_val() and g_array_insert_val()
macros required an user to use literals to add a new value.
This could be inconvenient at times, but it's possible to avoid this with
recent compilers, in fact in case glib_typeof is defined we can take
advantage of it, to initialize a temporary variable to store the literal
value and pass its address to the actual function.
The array of offsets is little-endian, even on big-endian architectures
like s390x.
Fixes: ade71fb5 "gvariant: Don’t allow child elements to overlap with each other"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2839
Signed-off-by: Simon McVittie <smcv@collabora.com>
I noticed this when running the test on an Arm Morello system where varargs
have bounds. g_variant_new() was trying to read an integer using va_arg(),
but since there was no argument it resulted in a bounds errors there.
On most other architectures this will just read whatever value is contained
in the next argument register and is not something that ASan can detect, so
it never resulted in test failures.
posix_memalign() requires the alignment to be a multiple of sizeof(void*),
and a power of 2. Passing 8 does not fulfil both of those constraints on
Arm Morello which resulted in a "posix_memalign failed" test failure.
Co-authored-by: Graeme Jenkinson <graeme@capabilitieslimited.co.uk>
When a cancellable is cancelled when we call g_cancellable_connect we
used to immediately call the provided callback, while this is fine we
actually had race in case the cancellable was about to be reset or in
the middle of a cancellation.
In fact it could happen that when we released the mutex, another thread
could reset the cancellable just before the callback is actually called
and so leading to call it with g_cancellable_cancelled() == FALSE.
So to handle this, make disconnect and reset function to wait for
connection emission to finish, not to break their assumptions.
This can be tested using some "brute-force" tests where multiple threads
are racing to connect and disconnect while others are cancelling and
resetting a cancellable, ensuring that all works as we expect.
This solves problems with validating untrusted inputs from D-Bus, where
invalid numbers of added and removed menu entries, and positions, could
be specified.
Original patch from
https://bugzilla.gnome.org/show_bug.cgi?id=728733#c7, tweaked by Philip
Withnall to add a few code comments and make
`G_MENU_EXPORTER_MAX_SECTION_SIZE` public so callers can check their
inputs against it if they want. Also tweaked to use `g_warning()` instead
of the nonexistent `g_dbus_warning()`.
Fixes: #861
If it takes one more `GMainContext` cycle than expected for the
`activate` signals to be handled, the `GApplication` under test can be
released too early, and the test will fail due to not seeing a high
enough value of `n_activations`.
Hopefully avoid that by moving the release to a low priority idle
callback.
This fix is only hopeful because I’ve only been able to reproduce the
failure on FreeBSD CI and not locally.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2835
This avoids needing to always serialise a variant before byteswapping it.
With variants in non-normal forms, serialisation can result in a large
increase in size of the variant, and a lot of allocations for leaf
`GVariant`s. This can lead to a denial of service attack.
Avoid that by changing byteswapping so that it happens on the tree form
of the variant if the input is in non-normal form. If the input is in
normal form (either serialised or in tree form), continue using the
existing code as byteswapping an already-serialised normal variant is
about 3× faster than byteswapping on the equivalent tree form.
The existing unit tests cover byteswapping well, but need some
adaptation so that they operate on tree form variants too.
I considered dropping the serialised byteswapping code and doing all
byteswapping on tree-form variants, as that would make maintenance
simpler (avoiding having two parallel implementations of byteswapping).
However, most inputs to `g_variant_byteswap()` are likely to be
serialised variants (coming from a byte array of input from some foreign
source) and most of them are going to be in normal form (as corruption
and malicious action are rare). So getting rid of the serialised
byteswapping code would impose quite a performance penalty on the common
case.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2797
If `g_variant_byteswap()` was called on a non-normal variant of a type
which doesn’t need byteswapping, it would return a non-normal output.
That contradicts the documentation, which says that the return value is
always in normal form.
Fix the code so it matches the documentation.
Includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2797
The entries in an offset table (which is used for variable sized arrays
and tuples containing variable sized members) are sized so that they can
address every byte in the overall variant.
The specification requires that for a variant to be in normal form, its
offset table entries must be the minimum width such that they can
address every byte in the variant.
That minimality requirement was not checked in
`g_variant_is_normal_form()`, leading to two different byte arrays being
interpreted as the normal form of a given variant tree. That kind of
confusion could potentially be exploited, and is certainly a bug.
Fix it by adding the necessary checks on offset table entry width, and
unit tests.
Spotted by William Manley.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2794
