All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
This makes calls to g_signal_connect_data() and g_signal_connect_object()
with default flags more self-documenting.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Also adds a test that checks that the G_SIGNAL_RUN flags are handled
correctly and the class signal handler is called at the right times.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/513
gobject/tests/signals.c: In function ‘test_introspection’:
gobject/tests/signals.c:1180:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
1180 | for (i = 0; i < n_ids; i++)
| ^
http://isvolatileusefulwiththreads.in/c/
It’s possible that the variables here are only marked as volatile
because they’re arguments to `g_once_*()`. Those arguments will be
modified in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
Add a test for a signal returning interface types, using
the generic marshaller. This will hopefully exercise newly
added code in value_from_ffi_type().
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.
