GClosure has been in the "allocate area before the pointer" game since
before we did this with GTypeInstance. At the time that this was done
for GClosure, we didn't have valgrind.h in GLib.
Now that we do, we should add similar valgrind hints as the ones we did
for GTypeInstance. This substantially reduces reports of "possibly
lost" on pretty much any program that makes use of signals.
https://bugzilla.gnome.org/show_bug.cgi?id=739850
It’s quite common to see a g_param_spec_pointer() used for GObject or
boxed types which, while not incorrect, does make memory management
unsafe, since no copying or reference counting can be performed
automatically.
Similarly, people often use g_param_spec_boolean() when an enum would be
more appropriate, cf.
http://blog.ometer.com/2011/01/20/boolean-parameters-are-wrong/
Using enums also means that the set of allowable values can be extended
in future if needed.
In the hope that people who write code like that read the documentation,
mention the more specific types in the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
This is pure read-only access to an external struct
so void warnings for people calling it from const
contexts such as accessors
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
switching to the old macros boilerplate to G_DECLARE_*
a lot of warnings start to pop when *_IS_A_* or such are
called from a const context.
Fix this by taking const pointers as parameters
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
This would allow bindings to use _get_option_group() functions, which
would then allow them to use GOption parsing.
This also adds introspection annotations to
g_option_context_add_group(), g_option_context_set_main_group() and
g_option_context_get_main_group().
https://bugzilla.gnome.org/show_bug.cgi?id=743349
Document each of the baked-in CClosure marshallers that we have in
gobject, along with their #GVaClosureMarshal equivalents.
Based on a patch from Xavier Claessens <xavier.claessens@collabora.com>.
Use the (private) _GLIB_DEFINE_AUTOPTR_CHAINUP macro for
G_DECLARE_DERIVABLE_TYPE and G_DECLARE_FINAL_TYPE so that we will
attempt to typedef and define items necessary for GCC
__attribute__((cleanup)) on, well, GCC only.
This fixes the build on non-GCC.
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Automatically add support for the new cleanup macros to the type
declaration macros.
This is an API break because now your parent class needs to support
cleanup if you want to use G_DECLARE_*_TYPE. These macros are only 1
day old, however, so that's probably not a big problem (and we are
already busy adding the macros all over GLib and Gtk+).
https://bugzilla.gnome.org/show_bug.cgi?id=743640
Add G_DECLARE_DERIVABLE_TYPE() and G_DECLARE_FINAL_TYPE() to allow
skipping almost all of the typical GObject boilerplate code.
These macros make some assumptions about GObject best practice that mean
that they may not be usable with older classes that have to preserve
API/ABI compatibility with a time before these practices existed.
https://bugzilla.gnome.org/show_bug.cgi?id=389585
Using G_STRLOC ends up embedding unique strings of the form
__FILE__:__LINE__ in the compiled binary. We can avoid these
by passing __FILE__ and __LINE__ separately when constructing
the warning text.
This probably reduces the size of the binary as __FILE__ is
likely already contained as string otherwise.
Note that for GCC 2.x this changes behavior because G_STRLOC
also contained __PRETTY_FUNCTION__.
https://bugzilla.gnome.org/show_bug.cgi?id=741654
Along the same lines as g_clear_object(), g_set_object() is a
convenience function to update a GObject pointer, handling reference
counting transparently and correctly.
Specifically, it handles the case where a pointer is set to its current
value. If handled naïvely, that could result in the object instance
being finalised. In the following code, that happens when
(my_obj == new_value) and the object has a single reference:
g_clear_object (&my_obj);
my_obj = g_object_ref (new_value);
It also simplifies boilerplate code such as set_property()
implementations, which are otherwise long and boring.
Test cases included.
https://bugzilla.gnome.org/show_bug.cgi?id=741589
Add GOBJECT_DEBUG=instance-count which enables internal accounting
of the number of instances of each GType, and g_type_get_instance_count()
to retrieve the result.
https://bugzilla.gnome.org/show_bug.cgi?id=354457
Not all instances have a TypeNode associated (e.g. GstEvent), so lets check if node is available
before trying to use it.
This crash can be easily reproduced by creating an event with gst_event_new_eos and using
G_IS_OBJECT on the event instance.
https://bugzilla.gnome.org/show_bug.cgi?id=733982
Practically no caller of these functions require atomic behaviour,
but the atomics are much slower than normal operations, which makes
it desirable to get rid of them. We have not done this before because
that would be a break of the ABI.
However, I recently looked into this and it seems that even if the
atomics *are* used for g_clear_* it is not ever safe to use this. The
atomics protects two threads that are racing to free a global/shared
object from freeing the object twice. However, any *user* of the global
object have no protection from the object being freed while in use,
because there is no paired operation the reads and refs the object
as an atomic unit (nor can such an operation be implemented using
purely atomic ops).
So, since nothing could safely have used the atomic aspects of these
functions I consider it acceptable to just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=733969
Don't emit property deprecation warnings for construct properties that
are being set to their default value during construction, but _do_ emit
them in all cases when the property was explicitly given to
g_object_new().
https://bugzilla.gnome.org/show_bug.cgi?id=732184
By default G_PARAM_DEPRECATED means absolutely nothing. We only emit a
warning if G_ENABLE_DIAGNOSTIC is set to '1' and then, only on sets.
Turn the logic on its head: emit the warning by default, unless
G_ENABLE_DIAGNOSTIC is set to 0. In order to avoid a torrent of output, only
emit a warning once per property name.
https://bugzilla.gnome.org/show_bug.cgi?id=732184
Used for the commonly used case (in signal emission) where we
initialize and set a GValue for an instance
Includes a fast-path for GObject
Overall makes it 6 times faster than the previous combination
of g_value_init + g_value_set_instance
Makes signal emission around 10% faster
https://bugzilla.gnome.org/show_bug.cgi?id=731950
These cause a static analyzer to think we're trying to actually handle
them being NULL, which is not the case. They both must not be NULL,
period.
No idea why the code was like this originally.
Reviewed by mclasen on IRC.
GParamSpec has a possibility of user-introduced flags, and we didn't
respect that with the addition of _EXPLICIT_NOTIFY.
Change the documentation for the maximum number of user flags to 10,
just to pick a somewhat random number. The documentation here was never
correct anyway -- it previously claimed that as many as 38 flags were
possible.
Meanwhile, move G_PARAM_EXPLICIT_NOTIFY next to _DEPRECATED in order to
avoid conflicts with low-numbered user flags (which are in use by at
least evolution-data-server).
https://bugzilla.gnome.org/show_bug.cgi?id=731341
A year ago, we tried to remove support for adding interfaces on
already-initialised types. There were problems with the C++ and C#
bindings at the time, so we added exceptions to give them a bit more
time to catch up.
It's already one cycle after when these exceptions were planned to be
removed, so let's take them out now.
https://bugzilla.gnome.org/show_bug.cgi?id=697229
Leave ourselves a little wiggle room: if people install properties after
initialisation then we reserve the right to handle that in a way that
may not be threadsafe.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
