If two GValues are transformable, it implies they are compatible,
so you do not need to check for compatibility yourself. Bump the
documentation to reflect this fact.
https://bugzilla.gnome.org/show_bug.cgi?id=707111
Stock GDB (both versions 7.0 and 7.1) does not come with the new
backtrace code and python API. To prevent an ugly python backtrace when
auto-loading gobject.py, let's catch the exception and not register the
FrameWrapper and the FrameFilter.
https://bugzilla.gnome.org/show_bug.cgi?id=613732
This is really just a very crude and limited conditional breakpoint.
Update the documentation to explain conditional breakpoints in
gdb instead. Also, remove the link to refdbg, which appears dead.
https://bugzilla.gnome.org/show_bug.cgi?id=719687
Take this test out of 'make check'. It's causing problems for a lot of people
due to fact that it's essentially a forkbomb. It's causing failures for Debian
on ARM and it's DoSing coredumps to system crash collectors.
The conditional only covers registration of the master, not the
subprocess parts. This is because g_test_slow() always return FALSE in
the subprocesses, so they would fail to run if we didn't register them
unconditionally.
This is the sole piece of code in GLib where we make use of the
stack growing direction. And this test proves that we have been
getting the direction wrong all these years...
The signals queued while notify is frozen are emitted in
reverse order, while omitting duplicates. The lack of documentation
for this was pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=607016
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
GMappedFile is current unintrospectable, because it's not a registered
box type. It already has reference counting functions, so there's
little reason not to box it.
This commit adds GMappedFile to the hoard of other boxes types handled
by gboxed.c
https://bugzilla.gnome.org/show_bug.cgi?id=712393
Rather than keeping a global list of objects that are being
constructed, use qdata on the object itself like we do with several
other properties now.
https://bugzilla.gnome.org/show_bug.cgi?id=661576
If a constructor() implementation created an object but then unreffed
it rather than returning it, that object would get left on the
construction_objects list, which would cause problems later when that
memory location got reused by another object.
"Fix" this by making it fail intentionally, and add a test for it (and
for the normal, working singleton case).
https://bugzilla.gnome.org/show_bug.cgi?id=661576
GBindingTransformFunc called its arguments "source_value" and
"target_value", but in the transform_from function of a bidirectional
binding, "source_value" comes from the target object, and
"target_value" comes from the source object, which quickly gets
confusing if you need to use g_binding_get_source(), etc, in the
function.
Of course developers can call their transform function arguments
whatever they want, but many will copy from the headers/docs to start
out, so use less confusing names here ("from_value" and "to_value").
Also, fix the documentation to describe the bidirectional case
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=709440
Add NULL check and return after calls to g_param_spec_internal in GParamSpec
creation functions. This avoids glib crashing due to things like badly named
properties.
https://bugzilla.gnome.org/show_bug.cgi?id=707887
Apple's GCC compilers cannot deal well with 64-bit pointers in
transparent unions on ppc64, so compilation of
_G_DEFINE_BOXED_TYPE_BEGIN was failing. Fortunately glib already
provides a fallback for compilers that can't deal with it; this adds
this specific case to the check.
https://bugzilla.gnome.org/show_bug.cgi?id=647145
g_type_class_add_private() was doing
g_assert (node->data->instance.private_size <= 0xffff);
but that field is a guint16, so the check was a no-op. (Noticed by
clang, but not gcc for some reason.) Fix it to do the math in a gssize
variable and do the bounds checking there before updating the struct
field.
https://bugzilla.gnome.org/show_bug.cgi?id=706888
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
Fix the warnings when compiling and linking the probes files by
calling dtrace with all the -W flags removed from CFLAGS (since dtrace
generates bad C code), and with CC set to "libtool --mode=compile ..."
(so that it will output a proper .lo file and libtool won't warn when
linking it into the .la).
https://bugzilla.gnome.org/show_bug.cgi?id=693335
Just like g_object_notify, check for a zero ref_count in
g_object_notify_by_pspec and leave if it is 0.
This allows using functions in ->finalize() that possibly also
notify a property change on the object. Previously,
this resulted in an error from g_object_ref.
https://bugzilla.gnome.org/show_bug.cgi?id=705570
