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
g_type_is_fundamentally_a (see bug 730984) is a new API/ABI and is
marked with a version macro. We should therefore avoid its
unconditional use from G_IS_OBJECT() and G_IS_PARAM_SPEC() which are
APIs that have been around for a long time.
This prevents deprecation warnings from being emitted when these
functions are used with an older GLIB_VERSION_MAX_ALLOWED and also
prevents linking to the new ABI in that case (so that it's possible to
use the resulting binary with an older version of GLib).
https://bugzilla.gnome.org/show_bug.cgi?id=731335
Add a flag to prevent the automatic emission of the "notify" signal
during g_object_set_property().
If this flag is set then the class must explicitly emit the notify
for themselves. This is already standard practice on most classes, but
we cannot simply remove the existing behaviour because there are surely
many cases where it is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=731200
Construct properties are always set during construction.
It makes no sense to warn about this even if the property
is marked as deprecated; the deprecation warning should
only be issues for explicit uses of the property after
construction.
https://bugzilla.gnome.org/show_bug.cgi?id=730045
- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.
https://bugzilla.gnome.org/show_bug.cgi?id=728983
On initialisation, GObject guarantees to zero-fill
class/object/interface structures. Document this so people don’t spend
forever writing:
my_object->priv->some_member = NULL;
my_object->priv->some_other_member = NULL;
https://bugzilla.gnome.org/show_bug.cgi?id=729167
These did show up in the html. Since symbol names are checked for a
trailing plural s when generating the docs, the links stay functional
after removing these comments.
https://bugzilla.gnome.org/show_bug.cgi?id=728380
Since the type system does not support reloading its data and assumes
that libgobject remains loaded for the lifetime of the process, we
should link libgobject with a flag indicating that it can't be unloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=707298
We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
Although returning NULL from constructor is strongly discouraged, some
old libraries need to keep doing it for ABI-compatibility reasons.
Given this, it's rude to forbid finalization from within
constructor(), since it would otherwise work correctly now anyway (and
the critical when returning NULL should discourage any new uses of
returning NULL from constructor()).
https://bugzilla.gnome.org/show_bug.cgi?id=661576
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
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
We need a TypeName_private_offset variable defined by the macros used to
register dynamic types. We also need to call the adjust_private_offset()
function inside class_init(). G_ADD_PRIVATE_DYNAMIC only sets the size
of the private data structure, and relies on the behaviour of the
g_type_class_adjuset_private_offset() function to register the private
data structure at class init time if passed a value greater than zero.
This allows using G_PRIVATE_OFFSET with dynamic types.
Otherwise in e.g. the gnome-ostree integrationtest system, we
end up sending SIGUSR1 to the *entire session*, which triggers
various badness in untested debugging paths from gnome-session.
This test worked when compiled without optimization, but fails with
-O2. Presumably we just happened to find the GMainLoop off the stack
somewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=704267
GPid is a HANDLE (aka void *) on Windows, not an int, so treat pid
accordingly on Windows, as using pid as a gulong directly would likely be
undesirable on Windows
https://bugzilla.gnome.org/show_bug.cgi?id=704447
- Mention G_SOURCE_CONTINUE and G_SOURCE_REMOVE in the GSourceFunc doc;
- Mention G_PARAM_READWRITE and G_PARAM_STATIC_STRINGS in the
GParamFlags doc;
- Fix "Since:" version for G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE;
- Fix typo.
https://bugzilla.gnome.org/show_bug.cgi?id=704250
For the glib-defined source types, and any source type that defines a
closure callback but not a closure marshal, use
g_cclosure_marshal_generic. And then remove all the other remaining
source closure marshals.
https://bugzilla.gnome.org/show_bug.cgi?id=701511
When using the GLIB_VERSION_MAX_ALLOWED macro to define the upper bound
of allowed API the G_DEFINE_TYPE_EXTENDED starts warning about the newly
added g_type_class_adjust_private_offset() function; this effectively
introduces a run-time dependency on GLib 2.38 even if we don't use its
API explicitly.
https://bugzilla.gnome.org/show_bug.cgi?id=703191
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
For static types, it should be possible to register a private data
structure right when we are registering the type, i.e. from the
get_type() implementation. By allowing this, we can take advantage of
the existing type definition macros to cut down the amount of code
necessary (as well as the knowledge baggage) when creating a new type.
The main issue with this new feature is that it cannot be mixed with the
old idiomatic way of adding private instance data by calling a function
in the middle of the class_init() implementation, as that imposes the
additional constraint of initializing the whole type hierarchy in order
to retrieve the offset of the private data in the GTypeInstance
allocation.
For this reason we are going to follow a two-step process; in the first
step, we are going to introduce the new (semi-private) API to register
the intent to add private instance data from within the get_type()
implementation, and hide it behind a macro; at the same time, the
G_DEFINE_TYPE_EXTENDED macro is going to be modified so that it will
register the private instance data if the macro was used, using a new
(semi-private) function as well. Once we have migrated all our code, we
will make the first new function perform the actual private data
registration, and turn the second new function into a no-op. This should
guarantee a transparent migration of existing code to the new idiomatic
form.
https://bugzilla.gnome.org/show_bug.cgi?id=700035
The automatic memory management of GBinding is not optimal for high
order languages with garbage collectors semantics. If we leave the
binding instance inert but still referenced it will be leaked, so one
solution that does not throw away the baby of C convenience with the
bathwater of language bindability is to have unbind() perform an
implicit unref().
Hopefully, C developers will read the documentation and especially the
note that says that after calling unbind() the reference count on the
GBinding instance is decreased.
https://bugzilla.gnome.org/show_bug.cgi?id=698018
We have turned up enough cases of this being done (including GTK API
allowing apps to do this to GtkSettings well after it has been
instantiated) that it is clear that we cannot really break this feature
while claiming to be backwards compatible.
For that reason, it becomes a warning rather than a critical (ie: it is
still well-defined behaviour, but you are discouraged from doing it).
The intention is to keep this feature for at least the next while.
A given GObjectClass will be able to avoid using GParamSpec pool for as
long as you don't install properties after init. If you do that, you
will get a warning and we will devolve to using GParamSpecPool.
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
GObject has previously allowed installing properties after class_init
has finished running. This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.
A previous patch asserted that this was not true and we had to revert it
because it broke the shell. Instead of reverting, we should have used a
critical, so do that now.
Complaints go to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
