Commit Graph

296 Commits

Author SHA1 Message Date
Emmanuele Bassi
f62622fc7b docs: Start stanzas with a single paragraph
When rendering the contents of the GLib documentation stored inside the
introspection data, a common behaviour is to take the first paragraph as
a summary of the symbol being documented.

The documentation is assumed to be in Markdown format, which means:

 - paragraphs must be separated by newlines
 - lines that have an indentation of four or more spaces are considered
   code blocks
 - lines that start with a `#` are considered titles

This means we need to slightly tweak the documentation in our sources to
ensure that it can be rendered appropriately by tools that are not
gtk-doc.

See issue: #2365
2021-08-02 13:22:23 +01:00
Allison Ryan Lortie
3764c6730e GObject: add g_object_take_ref()
This works in the same way as g_variant_take_ref(), and for the same
reason.

Updated and Rebased by Nitin Wartkar <nitinwartkar58@gmail.com>

Closes #1112
2021-06-11 18:13:34 +05:30
Jasper St. Pierre
edb40c7171 gobject: Allow passing %NULL for @data in g_object_remove_toggle_ref
gjs has some situations where it's not always aware of the @data that
was passed into g_object_add_toggle_ref, so allow passing %NULL to
just match on @notify.

Rebased and updated by Nitin Wartkar

Closes #817
2021-05-27 21:09:45 +05:30
Emmanuele Bassi
e97ebfe628 Fix the transfer annotations for GClosure constructors
The GClosure constructors in GObject return an instance with a floating
reference.

Fixes: #2299
2021-01-19 11:36:01 +02:00
Sebastian Dröge
a2de4b2479 Clarify in g_object_weak_ref() docs that the callback is called during disposing and not finalizing
This especially has the effect that any GWeakRefs to the object will not
necessarily be set to NULL yet if called as part of
g_object_run_dispose() and not as part of g_object_unref().
2020-12-08 18:09:50 +02:00
Philip Withnall
77361ef45e Merge branch 'fix_extra_warnings' into 'master'
Fix more warnings

See merge request GNOME/glib!1765
2020-11-24 15:37:21 +00:00
Emmanuel Fleury
236d6281b8 Fix signedness warnings in gobject/gobject.c:g_object_new_internal()
gobject/gobject.c: In function ‘g_object_new_internal’:
gobject/gobject.c:1962:25: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1962 |           for (j = 0; j < n_params; j++)
      |                         ^
gobject/gobject.c:1989:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1989 |       for (i = 0; i < n_params; i++)
      |                     ^
2020-11-24 16:17:46 +01:00
Emmanuel Fleury
7753a0492b Fix signedness warnings in gobject/gobject.c:g_object_new_with_custom_constructor()
gobject/gobject.c: In function ‘g_object_new_with_custom_constructor’:
gobject/gobject.c:1836:21: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1836 |       for (j = 0; j < n_params; j++)
      |                     ^
gobject/gobject.c:1914:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
 1914 |   for (i = 0; i < n_params; i++)
      |                 ^
2020-11-24 16:17:46 +01:00
Emmanuel Fleury
d50d2098b5 Fix signedness warning in gobject/gobject.c:g_object_class_install_properties()
gobject/gobject.c: In function ‘g_object_class_install_properties’:
gobject/gobject.c:766:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’}
  766 |   for (i = 1; i < n_pspecs; i++)
      |                 ^
2020-11-24 16:17:46 +01:00
Philip Withnall
9f041c9e05 Merge branch 'th/gobject-new-parameter-list' into 'master'
gobject: allocate parameter list for g_object_new_valist() entirely on stack

See merge request GNOME/glib!1385
2020-11-21 22:55:55 +00:00
Philip Withnall
08d04d0428 gobject: Drop unnecessary volatile qualifiers from internal variables
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.

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

Helps: #600
2020-11-20 14:40:19 +00:00
Thomas Haller
fb3977e9b4 gobject: limit required stack by heap allocating parameter list in g_object_new_valist()
The previous code consumed a larger additional amount of stack space.
That is because it would allocate the temporary buffer for GValues on
the stack with "g_newa (GValue, 1)" and thus the required stack
space grew with the number of arguments. Granted, this is already
a variadic C function, so the caller already placed that many elements
on the stack. For example, on the stack there are the property names
and the pointers to the arguments, which should amount to roughly
O(n_args * 16) (on 64 bit, with pointers being 8 bytes large).

That is not bad, because it means in the previous version the stack space
would grow linear with the already used stack space. However, a GValue is
an additional 24 bytes (on 64 bit), which probably more than doubles the
required stack space. Let's avoid that, by allocating the temporary list
on the heap after a certain threshold. This probably more than doubles the
number of possible arguments before the stack overflows.

Also, previously the heap allocated "params" array only grew one element
per iteration. Of course, it is likely that libc anyway reallocates
the buffers by growing the space exponentially. So realloc(ptr, 1)
probably does not O() scale worse than doubling the buffer sizes ourselves.
However, it seems clearer to keep track of the allocated sizes ourself, and
only call realloc() when we determine that we are out of space.
Especially because we need to update the value pointers on reallocation.

Note that we now require a heap allocation both for the "params" and the
"values" list. Theoretically that could be combined by using one buffer
for both. But that would make the code more complicated.

Now we pre-allocate buffers for 16 elements on the stack. That
is (16 * (16 + 24) bytes (or 640 bytes) on the stack. I think that
is still acceptable.
2020-11-18 15:26:14 +01:00
Thomas Haller
355c99a077 object: use guint type for n_params argument of g_object_new_is_valid_property()
Two out of three callers pass the count argument from a variable
of type guint. And the third is currently an always positive gint.

We should use the correct integer type that matches the type as it
used otherwise.
2020-11-18 13:38:53 +01:00
Philip Withnall
4f2b1e250d gobject: Standardise on the term ‘instantiatable’
Rather than using a mixture of ‘instantiable’ and ‘instantiatable’
everywhere, standardise on the term which is already in the public API.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2020-11-02 17:22:01 +00:00
Philip Withnall
41937c3631 gobject: Document that g_object_new() zeros out private data
It’s already mentioned at
https://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation,
but is important enough that mentioning it in the documentation for
`g_object_new()` seems helpful.

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

Fixes: #1022
2020-07-27 01:57:57 +01: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
Edward Hervey
898baa07b1 gobject: Handle runtime checks as such
The various `g_strdup_printf()` returns values in the implementations of GValue
lcopy_func are runtime checks which could be disabled if one wants and therefore
should be handled as such with g_return_val_if_fail()
2020-05-20 17:37:46 +02:00
Philip Withnall
641bbd0848 gobject: Clarify assertion failure on ref-after-finalize
Rename the variables involved so that people get a slightly more
obvious critical warning when they try to ref an object which has
already been finalised.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2020-03-23 11:48:22 +00:00
Philip Withnall
2474c65037 docs: Clarify handling of 64-bit integer literals with g_object_new()
As with `g_variant_new()` (or any varargs function which takes integer
literals of differing widths), callers need to be careful to ensure
their integer literals have the right width.

Tweak the documentation for `g_object_new()`, `g_object_set()` and
`g_object_get()` to clarify this. The documentation for `g_object_get()`
shows that it is not subject to the same caveats, since it operates on
pointers.

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

Closes: #833
2019-12-17 12:23:19 +00: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
Дилян Палаузов
512655aa12 minor typos in the documentation (a/an) 2019-08-24 19:14:05 +00:00
Philip Withnall
c178c9734c Merge branch 'static_analysis_2_40_patches' into 'master'
Static analysis 2 40 patches

Closes #905

See merge request GNOME/glib!1042
2019-08-24 14:22:38 +00:00
Colin Walters
7b0139b9f4 gobject/gobject.c: Tweak conditional to pacify static analysis
It can't easily see that value is always non-NULL here;
this equivalent tweak will show that it is.
2019-08-24 15:55:49 +02:00
Simon McVittie
41d31cd4b7 g_object_get_property: Document accepting G_VALUE_INIT as new API
Code intended to be portable to older versions of GLib cannot rely
on this being considered valid.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-08-01 09:29:52 +01:00
Simon McVittie
bf8b669061 g_object_get_property: Clarify meaning of G_TYPE_INVALID
"Uninitialized value" is partially correct, since it has not been
initialized with a type, but it's more precise to say
"zero-initialized value". It is still a programming error to pass a
pointer to uninitialized memory with arbitrary contents as the value.

Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-08-01 09:29:52 +01:00
Christian Hergert
2a4b5caac2 gobject: remove use of generic marshaller from GObject
Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.

Related to GNOME/Initiatives#10
2019-06-17 16:13:53 -07:00
Philip Withnall
fa5996927f Merge branch 'drop-g-disable-deprecated' into 'master'
Drop G_DISABLE_DEPRECATED

Closes #1060 and #638

See merge request GNOME/glib!871
2019-06-14 11:24:25 +00:00
Sebastian Dröge
db27933236 Merge branch 'docs-typo-fix' into 'master'
gobject: Fix apostrophe usage in a few small bits of documentation

See merge request GNOME/glib!853
2019-06-11 11:21:52 +00:00
Emmanuele Bassi
56a56f1ee5 Allow calling get_property() with an uninitialized GValue
We already have the GType with which the GValue should be initialized,
so requiring an initialized GValue is not really necessary, and it
actually complicates code that wraps GObject, by requiring the retrieval
of the GParamSpec in order to get the property type. Additionally, it
introduces a mostly unnecessary g_value_reset().

We already changed g_object_getv() to allow passing uninitialized
GValues, but this fell through the cracks.

Closes: #737
2019-06-04 20:05:24 +01:00
Philip Withnall
40ff475977 Annotate various types and macros as deprecated
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.

This is based on the list of deprecations from the reverted commit
80fcb1bc2.

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

Fixes: #638
2019-05-30 10:39:11 +01:00
Emmanuele Bassi
8b2f6a5523 Please don't use GInitiallyUnowned and floating refs
This place is not a place of honor… No highly esteemed API is implemented
here… Nothing valued is here.
2019-05-21 11:34:04 +01:00
Emmanuele Bassi
a734a92408 Document the best practice for binding InitiallyUnowned
Right now, the documentation is less than explicit on how language
bindings should handle GInitiallyUnowned.
2019-05-21 11:34:04 +01:00
Philip Withnall
f093ef6a6f gobject: Fix apostrophe usage in a few small bits of documentation
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2019-05-17 17:39:40 +01: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
3d3ca9f1fe gobject: Fix various compiler warnings when compiling with G_DISABLE_ASSERT
Mostly unused variables which are only used in a g_assert() call
otherwise.

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

Helps: #1708
2019-03-08 19:46:21 +00:00
Philip Withnall
2a570dc5af gobject: Mention quark memory usage for g_object_set_data()
g_object_set_data() should only ever be used with a small, bounded set
of keys, or the memory usage of the quark lookup table will grow
unbounded. Document that.

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

Fixes: #682
2019-03-07 10:56:47 +00:00
Tomasz Miąsko
c4cb27d844 gobject: Use atomic operations to read object reference count 2019-02-22 18:09:32 +01:00
Tomasz Miąsko
d72192f69b gobject: Remove unsynchronized read of freeze_count
There is no need to preserve the check, since check is performed again
while holding the notify_locks that protects freeze_count.
2019-02-22 17:51:48 +01:00
Colin Walters
4631cd892d gobject: Change assertions to read values via atomics
I'm trying to use `-fsanitize=thread` for OSTree, and some of
these issues seem to go into GLib.  Also, the sanitizers work better if
the userspace libraries are built with them too.

This fix is similar to
b6814bb37c

Mixing atomic and non-atomic reads trips TSAN, so let's change the
assertions to operate on the local values returned from atomic
read/writes.

Without this change I couldn't even *build* GLib with TSAN, since we
use gresources during compilation, which uses GSubprocess, which hits
this code.

(Minor review fixes made by Philip Withnall <withnall@endlessm.com>.)

https://gitlab.gnome.org/GNOME/glib/issues/1224
2019-01-31 13:18:40 +00:00
Philip Withnall
b9a8c03915 gobject: Convert a debug check from an assertion to a g_critical()
An assertion is harder to skip over, and using a g_critical() can give
us a more informative error message.

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

https://gitlab.gnome.org/GNOME/glib/issues/179
2018-10-11 11:40:12 +13:00
Philip Withnall
59a23bf24d gclosure: Minor documentation formatting improvements
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-08-16 10:59:45 +01:00
Philip Withnall
2500dfe3b3 docs: Fix a documentation link
Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-07-30 21:15:57 +01:00
Iain Lane
2aacef39b1 gobject: Make g_clear_object take a non-volatile GObject **
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.

Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
2018-07-12 08:47:40 +01:00
Emmanuele Bassi
d3881bb1bf Revert "Merge branch 'type-safe-g-clear-pointer-1425' into 'master'"
This reverts merge request !165
2018-07-11 21:52:31 +00:00
Iain Lane
747c2f5720 gobject: Make g_clear_object take a non-volatile GObject **
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.

Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
2018-07-11 10:52:53 +01:00
Daniel Boles
042ab215b2 GObject: Clarify 8db5542803 by avoiding double -ve
Make the wording easier to understand by saying what we do, rather than
what we avoid doing if the relevant thing did not happen!
2018-04-22 15:03:03 +01:00
Tomasz Miąsko
a9ad793506 gobject: Mark g_object_new_with_properties as non-introspectable
There is no transfer annotation that can express transfer semantics of
g_object_new_with_properties in general. When GInitiallyUnowned object
is constructed the introspection data will be incorrect.

Mark it with skip annotation.

https://bugzilla.gnome.org/show_bug.cgi?id=795025
2018-04-10 12:57:19 +01:00
Daniel Boles
8db5542803 GObject: Elaborate notify emission timing, options
We only said receiving ::notify doesn’t always guarantee that anything
actually changed, but we didn’t explain how we can get that guarantee.

https://bugzilla.gnome.org/show_bug.cgi?id=795096
2018-04-09 13:56:01 +01:00
Philip Withnall
809c66639f gobject: Mention transfer semantics of installing properties on GObjects
GParamSpec supports floating references.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
2018-02-14 15:11:11 +00:00