Making this validation code public allows projects to validate a
GParamSpec name before creating it. While hard-coded GParamSpec don't
need this, we can't afford crashing the main program for dynamically
generated GParamSpec from user-created data.
In such case, we will need to validate the param names and return errors
instead of trying to create a GParamSpec with invalid names.
Includes modifications from Philip Withnall and Emmanuele Bassi to
rearrange the new function addition and split it into one function for
GParamSpecs and one for GSignals.
It provides more useful output on failure, and isn’t compiled out when
building with `G_DISABLE_ASSERT`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than adding a canonicalised and non-canonicalised version of the
signal to `g_signal_key_bsa`, just add the canonicalised version. Signal
lookups always use the canonicalised key (since the previous commit).
This saves space in `g_signal_key_bsa`, which should speed up lookups;
and it saves significant space in the global `GQuark` table (a 9.6%
reduction in entries in that table, by a rough test using
gnome-software).
We have to be a little more relaxed on the signal name validation than
we are for property name validation, as GTK installs a
`-gtk-private-changed` signal which violates the signal naming rules.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
On Windows and possibly other platforms the '%p' printf modifier does
not prefix printed values with '0x', so do not expect the warning
message to contain the '0x' prefix for the handler pointer value.
This will not catch the case where we fail in libffi and always use 0.
In fact, be a real annoying person and use (1 << 31) as a flags value to
test signedness, too.
Also update the testcase to actually use flags everywhere and ot uint.
https://bugzilla.gnome.org/show_bug.cgi?id=754882
This is the sole piece of code in GLib where we make use of the
stack growing direction. And this test proves that we have been
getting the direction wrong all these years...
Basically due to a combination of va_args semantics around
signed/unsigned ints, this test case fails on ppc64. At the moment,
we have as yet to find any real-world consumer with such a large
enumeration value.
Unfortunately, the possible fixes for this are extremely invasive;
we would have to define a new enum API.
Given both of these facts, we believe it makes the most sense at the
current time to simply not test this. If we at a later time determine
there is such a real-world consumer, we can look at doing the
necessary fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=686662
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
If the closure is invalidated we drop the ref on the signal handler
node, but if the signal is currently being dispatched, the ref could be
held elsewhere.
Flag that we no longer have an outstanding invalidation handler so that
we don't try to unregister ourselves when the other ref drops.
Add a testcase that catches this situation.
In some cases, signal arguments have to be collected, even if there are i
no signal handlers connected (e.g. for GVariant parameters, where collection
consumes a floating variant).
Based on a patch by Christian Persch.
Bug #643624.
