Higher order languages with garbage collection can have issues releasing
a binding, as they do not control the last reference being dropped on
the binding, source, or target instances.
https://bugzilla.gnome.org/show_bug.cgi?id=698018
The way of getting the default value out of a GParamSpec is to allocate
a GValue, initialise it, then call g_param_spec_set_default() to set the
default value into that GValue.
This is exactly how we handle setting the default value for all of the
construct properties that were not explicitly passed to g_object_new().
Instead of doing the alloc/init/store on all construct properties on
every call to g_object_new(), we can cache those GValues in the private
data of the GParamSpec itself and reuse them.
This patch does not actually make that change to g_object_new() yet, but
it adds the API to GParamSpec so that a future patch to GObject can make
the change.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
Add a check to prevent adding an interface to a class that has already
had its class_init done.
This is an incompatible change but it is suspected that there are not
many users of this functionality. Two known exceptions are pygobject
(fixed in bug 686149) and our own testsuite (affected tests have been
temporarily disabled by this patch).
Once we confirm that nobody else is using this functionality we can
remove a rather large amount of code for dealing with this case.
https://bugzilla.gnome.org/show_bug.cgi?id=687659
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.
The ability to cross-compile glib got broken after the
merge of the 'signal-performance' branch as the assumption
was made that the generated glib-genmarshal can be executed
on the host (which isn't valid when cross-compiling).
Fixed this by using the just-built glib-genmarshal for normal
compilations and the native (host) glib-genmarshal when doing a
cross-compilation as was also done in several other areas of GLib
Tested for host=x86_64-unknown-linux-gnu, target=x86_64-unknown-linux-gnu
and host=x86_64-unknown-linux-gnu, target=i686-w64-mingw32
https://bugzilla.gnome.org/show_bug.cgi?id=671676
Transforming a GValue holding flags from a GFlagsValue set that includes the 0
value (no flag bits set) into a string would loop until exhausting all the
available memory.
https://bugzilla.gnome.org/show_bug.cgi?id=670557
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
