At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
The C spec leaves conditional evaluation inside a macro expansion as
undefined behaviour. This means we cannot use constructs like:
GOBJECT_IF_DEBUG(OBJECTS, {
...
#ifdef BLAH
...
#endif
...});
Because compilers are entirely justified to ignore the conditional, or,
like in the case of MSVC, error out.
https://bugzilla.gnome.org/show_bug.cgi?id=769504
historically, DEBUG_CODE(gtype.c) and IF_DEBUG(gobject.c, gsignal.c)
macros are used to support debugging messages about object bookkeeping
and signal emission.
DEBUG_CODE has never been used in gtype.c. IF_DEBUG, when used, must be
accompanied by an extra #ifdef G_ENABLE_DEBUG. this is cumbersome.
this patch add a new macro GOBJECT_IF_DEBUG based on DEBUG_CODE as
a replacement for both DEBUG_CODE and IF_DEBUG.
https://bugzilla.gnome.org/show_bug.cgi?id=729914
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool. In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.
The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.
Instead of trying to have dtrace run libtool we can have libtool run
dtrace. dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.
There appears to be some prior art for this approach. A quick search
shows that at least QEMU is using this approach. It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.
This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file. I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=725902
Some compilers have trouble with such sequences. Visual C++ may or may
not generate a warning in this particular case depending on if the
local code page supports an ellipsis.
https://bugzilla.gnome.org/show_bug.cgi?id=767218
glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.
This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`. This is due to a namespace clash.
One fix would be to rename the gdb helper files to not clash with
other Python modules. This should be done for all such helper files.
https://bugzilla.gnome.org/show_bug.cgi?id=760186
v_long is 32 bits on Win64, v_pointer is 64 bits. On most other platforms the
size of long and pointer is the same, so it's usually not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=758738
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
This reverts commit a3a9664ed2.
Constifying the autogenerated get_instance_private functio makes C++
compilers and GCC with -Wcast-qual warn during compilation of GLib and
projects depending on GLib.
Since using const with GObject instances is not a common coding
practice, it's better to revert than trying to make every sigle GType
function const-safe (and possibly add more compiler warnings in the
process).
https://bugzilla.gnome.org/show_bug.cgi?id=745068
This reverts commit 52f23db74a.
Constifying these macros make C++ compilers and GCC with -Wcast-qual
warn during compilation of GLib and projects depending on GLib.
Since using const with GObject instances is not a common coding
practice, it's better to revert than trying to make every sigle GType
function const-safe (and possibly add more compiler warnings in the
process).
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Add ref-func, unref-func, set-value-func, and get-value-func annotations to
GParamSpec so that it can be managed generically as a fundamental type with
introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=710243
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=755609
It seems that VS 2015 optimizes out the constructor on windows,
so it is better to use a DllMain to initialize the library
and keep using a normal constructor on the other platforms.
This research was done by Arnav Singh.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
If --prefix is specified, marshaller_prefix is allocated and never
freed. It does not actually have to be allocated — just use the static
string from argv.
Coverity CID: 1325370
This reverts commit 8e362161d9.
There is a fundamental difference between g_value_peek_pointer() and
g_value_get_pointer(), and it's not just complexity: the latter checks
if the GValue holds a pointer type, whereas the former doesn't.
https://bugzilla.gnome.org/show_bug.cgi?id=755922
g_value_unset() only works with initialized value and will assert
if the GValue is zero-filled (or initialized with G_VALUE_INIT). Document
this behaviour and refer to g_value_clear() for a method that work on
both initialized and zero-filled GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
This change allow leaving a scope before g_value_init() has been
called. This would happen if you do:
{
g_auto(GValue) value = G_VALUE_INIT;
}
Or have a return statement (due to failure) before the part of
your code where you set this GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
This will not catch the case where we fail in libffi and always use 0.
In fact, be a real annoying person and use (1 << 31) as a flags value to
test signedness, too.
Also update the testcase to actually use flags everywhere and ot uint.
https://bugzilla.gnome.org/show_bug.cgi?id=754882
Keeping these enabled causes too many people to file
bugs against gobject, and not enough people to send
patches to port away from deprecated properties.
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.
I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=754986
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
We don't need to run binaries we just built in order to successfully
build GLib and friends any more.
Since commit b74e2a7, we don't need to run glib-genmarshal when building
GIO; since commit f9eb9eed, all our tests (including the ones that do
need to run binaries we just built) are only built when running "make
check", instead of unconditionally at every build.
This means that we don't need to check for existing, native binaries
when cross-compiling, and fail the configuration step if they are not
found — which also means that you don't need to natively build GLib for
your toolchain, in order to cross-compile GLib.
We can also use the cross-compilation conditional, and skip those tests
that require a binary we just built in order to build.
https://bugzilla.gnome.org/show_bug.cgi?id=753745
It’s quite common to see naked g_signal_connect() calls without a paired
g_signal_handler_disconnect(). This is commonly a bug which could lead
to uses of the callback user data after it’s been freed.
Document the best practices for avoiding this kind of bug by properly
disconnecting all signal handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=741779
Make it a little easier to find the GType conventions page, which I
guess should be the canonical guide to how to name things.
This adds a brief mention of the valid characters in a type name to the
conventions page.
https://bugzilla.gnome.org/show_bug.cgi?id=743018
We already do this in the normal case, might as well support it for the
dynamic type module case as well. This prevents seeing a warning when not
using the get_instance_private() in the dynamic type.
Using the register keyword triggers warnings on noteworthy compilers
(clang), since it's deprecated in C++ and at danger of being removed
from the language. There is no reason to use it since it isn't 1980
anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=750918
Prevents race condition in function g_io_condition_get_type by ensuring
that the initialization section for 'etype' is executed only once
during a program's life time, and that concurrent threads are blocked
until initialization completes. This changes solves the problem that
concurrent threads could execute the check 'etype == 0' before any of
them had initialized it, which in turn meant that multiple threads
would then attempt to register the "GIOCondition" type.
https://bugzilla.gnome.org/show_bug.cgi?id=750386
It isn't actually doing anything, instead it is
being managed without actually being used.
This has the result that GBinding is now more
thread-safe.
https://bugzilla.gnome.org/show_bug.cgi?id=745013
Add a global lookup table for signal handlers. We already give
them a unique ID, so there is no good reason to pay for
non-constant lookups when disconnecting handlers.
https://bugzilla.gnome.org/show_bug.cgi?id=737009
This test checks the performance of connecting, disconnecting and
blocking many handlers. Various cases are checked: disconnect in
the same order, in the inverse order, at random. Connect to one
signal on a single object, to two signals on the same object, or
to the same signal on two different objects.
https://bugzilla.gnome.org/show_bug.cgi?id=737009
Restricting the number of children to be less than 4095 can
be an issue when generating types. This is also an issue for
the Lua bindings as each Lua state will create a new GType each
time the Lua code is executed.
https://bugzilla.gnome.org/show_bug.cgi?id=747882
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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
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
