The GValueArray type was added in a time, during the Jurassic era or so,
when GArray did not have a representable GType. The GValueArray API has
various issues as well:
- it doesn't match the other GLib array types;
- it is not reference counted;
- the structure is fully exposed on the stack, so it cannot be
extended to add reference counting;
- it cannot be forcibly resized.
The nice thing is that now we have a GArray type that can replace in
full GValueArray, so we can deprecate the latter, and reduce the
complexity in GLib, application code, and bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=667228
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
We were previously preventing implementations of an interface from
specifying G_PARAM_CONSTRUCT for a property of that interface if the
interface didn't specify it itself (or was readonly).
This is something that should only interest the implementation, so we
remove this restriction.
This allows 6 new possible override scenarios:
- writable -> writable/construct
- writable -> readwrite/construct
- readwrite -> readwrite/construct
- writable/construct-only -> writable/construct
- writable/construct-only -> readwrite/construct
- readwrite/construct-only -> readwrite/construct
and we update the testcase to reflect this.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Add a testcase to check all possibilities for overriding a property
specified on an interface from an implementation of that interface,
changing the type and flags.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
First, some ARM systems are not fast enough to meet the 30 second
deadline in gwakeuptest.c, so increase that to 60.
Second, we have some signed/unsigned woes in the gparam transform tests.
These don't really matter, since it's test code, but they do obscure
real leaks in the library.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().
Change the wording in the docs. Clarify expectations for
(deprecated) g_thread_create().
These were the last users of the dynamic allocation API.
Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).
https://bugzilla.gnome.org/show_bug.cgi?id=660739
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
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.
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
The g_object_bind_property_with_closures() function should set a
marshaller if the two GClosures don't have one already. This simplifies
the caller code and avoids duplication.
We need to add a new marshaller to the gmarshal.list matching the
signature of the GBindingTransformFunc function.
Since GSettings got the same functionality and flag in commit ca3b7b75b
GBinding should also have the ability to automatically invert a boolean
value without requiring a custom transformation function.
Since using the function pointer version muddles the memory management
requirements of language bindings, we should implement a GClosure-based
variant on top of g_object_bind_property_full().
https://bugzilla.gnome.org/show_bug.cgi?id=622278
When creating a binding between two object properties we might want to
automatically synchronize the two values at the moment of the binding
creation, instead of waiting for the next change.
The G_BINDING_SYNC_CREATE flag does exactly what it says on the tin.
https://bugzilla.gnome.org/show_bug.cgi?id=622281
GBinding is a simple, opaque object that represents a binding between a
property on a GObject instance (source) and property on another GObject
instance (target).
https://bugzilla.gnome.org/show_bug.cgi?id=348080
It makes the IBM XL C Compiler (the 'native' non-free compiler
on the AIX 5.3 and 6.1 platform) stop compiling with syntax error.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=581300
Signed-off-by: Javier Jardón <jjardon@gnome.org>
