They do not start with the #!/usr/bin/python that would be necessary
to make them run with Python rather than a shell, and they would
not be useful to run anyway: they are libraries to be imported,
not scripts to be run.
Signed-off-by: Simon McVittie <smcv@debian.org>
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
The macros differ in their handling of NULL values — some macros ignore
them and pass through (e.g. G_TYPE_CHECK_INSTANCE_CAST) while others
will explicitly emit a warning if passed NULL (e.g.
G_TYPE_CHECK_INSTANCE).
Document their behaviour, so people don’t end up putting unnecessary
NULL checks in their code when doing checked type casts.
https://bugzilla.gnome.org/show_bug.cgi?id=735731
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
global variables in SystemTap are shared between all SystemTap scripts;
so if scripts are loaded for two versions of GLib (for example, a stable
and a development version), those global variables will conflict.
Avoid that by including the soname’s version in the global variable
names.
https://bugzilla.gnome.org/show_bug.cgi?id=770646
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
gtk-doc doesn’t make the return type clear, because these are macros
rather than inline functions, so people often have to guess at the
return type (or look it up from g_signal_connect_closure(), but that’s
hard work).
Make it clear that the return type for handler IDs is gulong. While
there, fix the capitalisation of ‘id’ to ‘ID’ in a few places.
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>
