Commit Graph

186 Commits

Author SHA1 Message Date
Loic Le Page
208593acc6 Fix redefinition of local variable and non-initialized variable in gobject/gsignal.c 2022-02-18 10:49:00 +01:00
Alexander Schwinn
28d833a075 Make clear in doc that signals are emitted synchroniously 2022-01-18 08:53:20 +00:00
Nishal Kulkarni
34cf69ef17 gsignal: Use new g_newa0() function
Replace old `g_alloca()` and `memset()` with `g_newa0()`
2021-11-26 12:24:23 +00:00
DarkTrick
3c459b7fd6 doc: Explicitly said, that no null term. is needed 2021-09-06 11:23:14 +00:00
Philip Withnall
f10101b909 gobject: Use g_memdup2() instead of g_memdup() in obvious places
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.

In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
2021-02-04 14:13:21 +00:00
Thomas Haller
8416211231 gsignal: use g_clear_signal_handler() macro to implement g_clear_signal_handler() function
We have a "good" implementation of g_clear_signal_handler() in
form of a macro. Use it, and don't duplicate the code.

Also add a comment to the documentation that "instance" in fact must
not point to a valid GObject instance -- if the handler ID is unset.

Also reword the documentation about the reasoning for why a macro
version exists. The reason is not to use the function "without
pointer cast". I don't think the non-macro version requires any
pointer cast, since "instance" is a void pointer. Was this referring
to the handler_id_ptr? That doesn't seem right either, because the
caller should always provide a "gulong *" pointer and nothing else.
2021-02-01 09:45:46 +01:00
Thomas Haller
cc4ffe4742 gsignal: use stack allocate temporary buffer in g_signal_new_valist()
g_signal_new_valist() is called by g_signal_new(), which is probably
the most common way to create a signal.

Also, in almost all cases is the number of signal parameters small.

Let's optimize for that by using a stack allocated buffer if we have
few parameters.
2021-02-01 09:43:29 +01:00
Emmanuele Bassi
8199fd65a9 Merge branch '2227-gobject-annotation-fixes' into 'master'
Add more GIR annotations to gparam.c and gsignal.c

See merge request GNOME/glib!1804
2021-01-19 11:35:15 +00:00
Sebastian Dröge
3581eda9a2 gsignal: Allow return types for RUN_FIRST-only signals too
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
2020-12-21 17:22:51 +00:00
Sebastian Dröge
9d1455444c gsignal: Add a new GSignalFlag to mark the first run of an accumulator function
Also add a test for signal accumulators. There was none before, and this
one now also covers the new flag.

Fixes https://gitlab.gnome.org/GNOME/glib/issues/514
2020-12-21 17:10:19 +00:00
Philip Withnall
7ad0c3a0f4 gsignal: Add (closure) and (destroy) annotations
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2020-12-12 18:08:40 +00:00
Philip Withnall
181a12c393 gsignal: Add missing (transfer) and (nullable) return annotations
This commit only looks at the `Returns:` lines in the documentation, and
has examined all of them in the file. Function arguments have not been
checked.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2227
2020-12-11 23:49:30 +00:00
Ray Strode
d691c2ebd2 gsignal: Plug g_signal_connect_object leak
commit 916297be79 added a hash table
to provide constant time lookups of signal handlers.

Unfortunately, that commit neglected to remove handlers from
g_signal_connect_object calls from the hash table that are
disconnected implicitly when the associated object goes away.

This commit addresses that bug by changing the closure invalidate
handler associated with the signal connection to properly remove the
handler from the hash table.
2020-10-13 09:49:29 -04:00
Philip Withnall
a63efa4291 tree: Fix various ableist language
In almost all cases, rewording the documentation/comments made things
more specific and a little clearer.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1544#note_846645
2020-06-23 10:49:44 +01:00
Philip Withnall
00bfb3ab44 tree: Fix various typos and outdated terminology
This was mostly machine generated with the following command:
```
codespell \
    --builtin clear,rare,usage \
    --skip './po/*' --skip './.git/*' --skip './NEWS*' \
    --write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).

Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.

There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.

If I’ve missed anything, please file an issue!

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-06-12 15:01:08 +01:00
Jehan
13d1697b67 gobject: Add g_{param_spec,signal}_is_valid_name() functions
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.
2020-03-04 14:46:28 +00:00
Philip Withnall
a07bc20557 gsignal: Drop unnecessary warnings from g_signal_lookup()
The `G_TYPE_IS_INSTANTIATABLE()` check is redundant with a precondition
on the function.

The `g_type_class_peek()` check seems like a pointless restriction: it
should be possible to check for a signal from a class init function.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #650
2019-12-12 13:00:54 +00:00
Emmanuele Bassi
ec3589b93f Merge branch 'signal-underscores' into 'master'
Signal name handling improvements

See merge request GNOME/glib!1224
2019-12-12 12:10:55 +00:00
Bastien Nocera
6fd2ea1dc6 docs: Fix "occurred" typos in API documentation 2019-11-21 13:07:08 +01:00
Philip Withnall
c577bc89cd gsignal: Warn if g_signal_lookup() is called on an invalid signal name
And add a test for it.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-11-15 11:06:14 +00:00
Philip Withnall
5e89ba5a74 gsignal: Clarify signal detail format
The format has never previously been specified. It can be anything, but
for sanity’s sake disallow empty strings.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #358
2019-11-15 11:06:14 +00:00
Philip Withnall
89f955db2d gsignal: Canonicalise signal names at installation time
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>
2019-11-15 11:06:14 +00:00
Philip Withnall
875e2afa55 gsignal: Canonicalise signal name when looking it up in an object
Previously, we’d look up the signal name as passed to (for example)
`g_signal_lookup()`, and rely on the fact that signals are inserted
twice into `g_signal_key_bsa`; once in canonical form and once not.

In preparation for only inserting signals into `g_signal_key_bsa` once,
we now try looking up a signal with the given signal name and, if that
fails, try canonicalising the name and trying again.

This is a performance hit on lookups for non-canonical names, but
shouldn’t affect the performance of lookups for canonical names. If
people want performance, they should use canonical names.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #358
2019-11-15 11:06:14 +00:00
Philip Withnall
90b51805b7 gsignal: Fold g_quark_try_string() call into signal_id_lookup()
This eliminates a call from every call site of signal_id_lookup(). It
introduces no functional changes, but allows subsequent refactoring.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-11-15 11:06:14 +00:00
Philip Withnall
b8eb6025f1 gsignal: Tidy up signal naming documentation
Since signal names are the same as property names, reference between the
two. Improve the formatting, and make it clearer that `_` is
discouraged.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #358
2019-11-15 11:06:14 +00:00
Philip Withnall
b43bfcaa68 Merge branch 'use-gobject-hole' into 'master'
Use the GObject hole on 64bit arches for some flags to improve performance

See merge request GNOME/glib!1083
2019-11-07 08:15:03 +00:00
Philip Withnall
9ca97b8b0b gsignal: Document class init before signals can be looked up
Fixes: #767

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-09-20 11:23:08 +02:00
Alexander Larsson
5afd574e91 Use the GObject hole on 64bit arches for some flags to improve performance
This uses a 32bit hole in the GObject structure on 64bit arches
as a flag field which can be optionally used for some preformance hints.

Currently there is a flag that gets set any time you connect to a signal
on a GObject which is used as early bailout for signal emissions, and using
the flags field instead of a user-data for checking if a GObject is
under construction.
2019-09-02 15:48:32 +02:00
Philip Withnall
12bd86a2ee Merge branch 'G_SIGNAL_RUN_CLEANUP_do_not_call_accumulate' into 'master'
Run the accumulator function for RUN_CLEANUP object handlers too

Closes #512

See merge request GNOME/glib!1053
2019-08-26 06:19:07 +00:00
Sebastian Dröge
153ac4c82a Run the accumulator function for RUN_CLEANUP object handlers too
Closes issue #512
2019-08-25 19:31:48 +02:00
Emmanuele Bassi
bcf208ba4c Bugs should be reported on GitLab
Not on mailing lists that do not exist any more.
2019-07-23 11:27:30 +01:00
Christian Hergert
266a292a35 gsignal: update documentation about va_marshaller
If we specify a c_marshaller, g_signal_newv() will never assign an
va_marshaller automatically. So either use NULL (for simple cases), or
specify both to avoid the generic performance penalty.
2019-06-17 14:07:26 -07:00
Marco Trevisan (Treviño)
409c1522bc gisgnal: Add g_clear_signal_handler
It allows to disconnect a signal handler from GObject instance and at the same
time to nullify the signal handler.

Provided also a macro for handler type conversion.
2019-05-20 13:33:41 -05:00
Philip Withnall
38de3e9dc3 docs: Use ‘look up’ as a verb, rather than the noun ‘lookup’
Another niggle fixed.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-04-26 12:12:31 +01:00
Philip Withnall
d388a00028 docs: Fix typo in gsignal.c documentation comment
Spotted by Morten Welinder <mortenw@gnome.org>.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=796186
2018-05-17 13:54:46 +01:00
Ryan Lortie
c64b6da33c gsignal: add assert on closure invalidate path
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.

Add an explicit assert here to quiet up static analysis.

See the bug for more discussion.

Coverity CID: 1159477

https://bugzilla.gnome.org/show_bug.cgi?id=730296
2017-11-15 12:51:12 +00:00
Stefan Sauer
2812219adb docs: add missing '*' chars at start of doc-comments 2017-11-12 16:36:16 +01:00
Sébastien Wilmet
6b948d9613 gobject/: LGPLv2+ -> LGPLv2.1+
All gobject/*.{c,h} files have been processed.

gmarshal.c and gmarshal.h don't have a license header.

https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-24 11:58:19 +02:00
Christian Hergert
18a33f72db introspection: use (nullable) or (optional) instead of (allow-none)
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.

It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
2016-11-22 14:14:37 -08:00
Philip Withnall
9f4d5e8b91 gsignal: Mention handler ID type in signal connection macro docs
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).

Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
2016-11-10 16:12:41 +00:00
Matthias Clasen
ef16cbee5b Don't set a va marshaller if a marshaller was set
Otherwise we get warnings when the caller later tries to set a
va marshaller with g_signal_set_va_marshaller.

https://bugzilla.gnome.org/show_bug.cgi?id=769076
2016-08-25 13:26:58 -04:00
Rico Tzschichholz
e3189527dc gio/gobject: Various introspection fixes 2016-02-03 18:13:49 +01:00
Philip Withnall
25a7c817d3 glib: Add missing (nullable) and (optional) annotations
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.

Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.

This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.

https://bugzilla.gnome.org/show_bug.cgi?id=719966
2015-11-07 10:48:32 +01:00
Alexander Larsson
69002f726d signal: return TRUE from g_signal_has_handler_pending for custom class closure
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.

I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().

https://bugzilla.gnome.org/show_bug.cgi?id=754986
2015-09-14 13:19:51 +02:00
Iain Lane
16721468e5 gsignal: Don't crash when operating on signals on the wrong object 2015-09-01 14:30:43 +01:00
Philip Withnall
ef1ba452b3 gsignal: Document memory management best practices for signal handlers
It’s quite common to see naked g_signal_connect() calls without a paired
g_signal_handler_disconnect(). This is commonly a bug which could lead
to uses of the callback user data after it’s been freed.

Document the best practices for avoiding this kind of bug by properly
disconnecting all signal handlers.

https://bugzilla.gnome.org/show_bug.cgi?id=741779
2015-08-19 12:56:38 +01:00
Matthias Clasen
916297be79 Add a global signal handler table
Add a global lookup table for signal handlers. We already give
them a unique ID, so there is no good reason to pay for
non-constant lookups when disconnecting handlers.

https://bugzilla.gnome.org/show_bug.cgi?id=737009
2015-05-27 14:41:19 -04:00
Philip Withnall
073a81d1da gsignal: Mark the return value of g_signal_emitv() as (inout) (optional)
https://bugzilla.gnome.org/show_bug.cgi?id=719966
2015-04-27 12:35:54 +01:00
Xavier Claessens
6a97275c45 docs: fix many documentation issues in gobject/ 2015-02-05 16:01:17 +01:00
Ryan Lortie
c476f7cd26 gsignal: add a clarification to the docs
As evidenced by a mistake that I made recently, this documentation could
use a little bit of clarification.
2014-11-28 16:22:16 -05:00