On Windows and possibly other platforms the '%p' printf modifier does
not prefix printed values with '0x', so do not expect the warning
message to contain the '0x' prefix for the handler pointer value.
When building a valist marshaller, we can avoid reffing a GParamSpec
if the argument is known to always be static. The marshaller we ship in
`gmarshal.c` got this right, but marshallers generated by
glib-genmarshal were missing the optimisation. Fix that, and add a unit
test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1792
Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.
Related to GNOME/Initiatives#10
If we specify a c_marshaller, g_signal_newv() will never assign an
va_marshaller automatically. So either use NULL (for simple cases), or
specify both to avoid the generic performance penalty.
When building a valist marshaller, we can avoid a string copy if the
argument is known to always be static. The marshaller we ship in
`gmarshal.c` got this right, but marshallers generated by
glib-genmarshal were missing the optimisation. Fix that, and add a unit
test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1792
The old (Perl) implementation of glib-genmarshal used
g_variant_ref_sink() to correctly handle floating inputs; the Python
version should do the same.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1793
This is a basic test suite for the `glib-genmarshal` utility, lifted
mostly directly from the tests for `glib-mkenums`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This makes the Meson build code for it a little more generic, and adds
support for installed tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
While this was useful for local testing while developing the test, it’s
not widely applicable. Look the binary up in the current `${PATH}` if
it’s not specified using `G_TEST_BUILDDIR`.
This is needed to get the `mkenums.py` test working as an
installed-test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We already have the GType with which the GValue should be initialized,
so requiring an initialized GValue is not really necessary, and it
actually complicates code that wraps GObject, by requiring the retrieval
of the GParamSpec in order to get the property type. Additionally, it
introduces a mostly unnecessary g_value_reset().
We already changed g_object_getv() to allow passing uninitialized
GValues, but this fell through the cracks.
Closes: #737
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
Use the new `GLIB_DEPRECATED_{TYPE,ENUMERATOR}*` macros to annotate types
and enumerators as deprecated, rather than using `G_DISABLE_DEPRECATED`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It allows to disconnect a signal handler from GObject instance and at the same
time to nullify the signal handler.
Provided also a macro for handler type conversion.
Since out-of-source-tree builds are now used after switching to meson,
we don't need .gitignore files in the source directories to ignore
build artifacts.
This fixes build errors when doing a meson build after an autotools
build, because generated files such as gio/xdp-dbus.c won't show up in
a `git status`, or be removed by a `git clean -f`, and so it won't be
obvious that such files need to be removed for the meson build to
succeed.
Currently, there is no way to prevent tests from building using meson.
When cross-compiling, building the tests isn't necessary.
Instead, only build the tests on the following conditions:
1) If not cross-compiling.
2) If cross-compiling, and there is an exe wrapper.
This reverts commit 80fcb1bc26.
G_DISABLE_DEPRECATED should never be used by anybody, least of all by
GLib. We have deprecation annotations for the compiler, these days, and
they are much better suited than a macro that makes symbols appear and
disappear. The fact that gtk-doc doesn't understand the deprecation
annotations is a limitation of gtk-doc, and it's gtk-doc that ought to be
fixed.
Commit 80fcb1bc broke GStreamer, which disables old API that was
deprecated before the introduction of the deprecation annotations, but
still uses newly deprecated one, and relies on the deprecation
annotations to do their thing. It also broke libsoup, as it uses
GValueArray in its own API.
This is not new; all of its methods have been deprecated for a long
time. Make the deprecation more obvious, however, by marking the whole
section as deprecated.
Note that GArray can’t *quite* do everything that GValueArray could.
See #1069 for work to fix this. This documentation block can be updated
again once that’s fixed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
As pointed out by gtk-doc, these are all symbols which have been marked
as deprecated, but which aren’t protected by a deprecation guard. We
can’t use G_DEPRECATED_IN_* for them, as they are all non-function
symbols. Instead, wrap them in #ifndef G_DISABLE_DEPRECATED.
In some cases, we also need to wrap one or two functions which use the
deprecated types in G_DISABLE_DEPRECATED too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to allow GLib itself to be built with G_DISABLE_ASSERT defined,
we need to explicitly undefine it when building the tests, otherwise
g_test_init() turns into an abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1708
g_object_set_data() should only ever be used with a small, bounded set
of keys, or the memory usage of the quark lookup table will grow
unbounded. Document that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #682
Grouping things together makes them easier to find and keep up to date.
This doesn’t modify any of the comments or make any functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
They were originally generated by glib-genmarshal, which documents its
output as being under the same license as the containing project. In
this case, that’s LGPL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The threads used to iterate at least 10000 times before setting the
"seen thread" flag to true. After porting they inadvertently did that
in the first iteration.
Previously, the test assumed that thread1 and thread2 would be scheduled
enough to set seen_thread{1,2} by the fact that the test runs for a high
number of iterations. On some platforms/schedulers, that’s not true,
which causes the test to spuriously fail.
Fix that by forcing the test to continue iterating until both threads
are seen. If this takes too long, the Meson test runner timeout will be
hit and the test will be terminated.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, all three threads would access several global variables
without locking.
Fix that by using atomic accesses to data stored within the
test_closure_refcount() function, which also eliminates the global state
(which would confuse further tests if they were added to this file).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert() can be compiled out if G_DISABLE_ASSERT is defined; and
g_assert_*() provide more specific error messages on failure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These functions are not run more than once, so the variables don’t need
to be static to save state between runs.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
GValue g_type field is used for synchronization with g_once_init_enter,
and so it should be written to only with g_once_init_leave.
Replace structure copy with memcpy that copies the one remaining field
of GValue, i.e., data array.
It's necessary sometimes for installed tests to be able to run with a
custom environment. For example, the gsocketclient-slow test requires an
LD_PRELOADed library to provide a slow connect() (this is to be added in
a followup commit).
Introduce a variable `@env@` into the installed test template, which we
can override as necessary when generating `.test` files, to run tests
prefixed with `/usr/bin/env <LIST OF VARIABLES>`.
As the only test that requires this currently lives in `gio/tests/`, we
are only hooking this up for that directory right now. If other tests in
future require this treatment, then the support can be extended at that
point.
I'm trying to use `-fsanitize=thread` for OSTree, and some of
these issues seem to go into GLib. Also, the sanitizers work better if
the userspace libraries are built with them too.
This fix is similar to
b6814bb37c
Mixing atomic and non-atomic reads trips TSAN, so let's change the
assertions to operate on the local values returned from atomic
read/writes.
Without this change I couldn't even *build* GLib with TSAN, since we
use gresources during compilation, which uses GSubprocess, which hits
this code.
(Minor review fixes made by Philip Withnall <withnall@endlessm.com>.)
https://gitlab.gnome.org/GNOME/glib/issues/1224
This is an analogous commit to c1f5e528. The original fix only touched
gtype.h and not gtypemodule.h.
The *_init() functions have prototypes incompatible with *InitFunc types they
are being cast to. This upsets GCC 8's -Wcast-function-type that's enabled by
default with -Wextra.
Let's not have the public header files emit a warning and neutralize it by
doing a void(*)(void) cast first.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1666
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
And mention why it’s not a GInterfaceInitFunc as people who have read
the GObject docs cover-to-cover might expect.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Note that it's not reported with gcc. It's only reported with g++.
C++ code to reproduce this warning:
#include <glib-object.h>
G_BEGIN_DECLS
#define GARROW_TYPE_FILE (garrow_file_get_type())
G_DECLARE_INTERFACE(GArrowFile,
garrow_file,
GARROW,
FILE,
GObject)
struct _GArrowFileInterface {
GTypeInterface g_iface;
};
G_DEFINE_INTERFACE(GArrowFile,
garrow_file,
G_TYPE_OBJECT)
static void
garrow_file_default_init(GArrowFileInterface *iface)
{
}
G_END_DECLS
Build command line:
% g++ -Wall -shared -o liba.so a.cpp $(pkg-config --cflags --libs gobject-2.0)
Message:
In file included from /tmp/local.glib/include/glib-2.0/gobject/gobject.h:24,
from /tmp/local.glib/include/glib-2.0/gobject/gbinding.h:29,
from /tmp/local.glib/include/glib-2.0/glib-object.h:23,
from a.cpp:1:
a.cpp: In function 'GType garrow_file_get_type()':
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:219:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
#define G_TYPE_MAKE_FUNDAMENTAL(x) ((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:2026:11: note: in definition of macro '_G_DEFINE_INTERFACE_EXTENDED_BEGIN'
if (TYPE_PREREQ) \
^~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:1758:47: note: in expansion of macro 'G_DEFINE_INTERFACE_WITH_CODE'
#define G_DEFINE_INTERFACE(TN, t_n, T_P) G_DEFINE_INTERFACE_WITH_CODE(TN, t_n, T_P, ;)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.cpp:16:1: note: in expansion of macro 'G_DEFINE_INTERFACE'
G_DEFINE_INTERFACE(GArrowFile,
^~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:178:25: note: in expansion of macro 'G_TYPE_MAKE_FUNDAMENTAL'
#define G_TYPE_OBJECT G_TYPE_MAKE_FUNDAMENTAL (20)
^~~~~~~~~~~~~~~~~~~~~~~
a.cpp:18:20: note: in expansion of macro 'G_TYPE_OBJECT'
G_TYPE_OBJECT)
^~~~~~~~~~~~~
Conceptually the binding is kept alive as long as both the source and
target exist. This means that an API user needs to take some care to
either hold a reference or only use a pointer to the binding as long as
also holding references to both objects.
Clarify the documentation a bit.
Turns out the fix in commit 93555577c wasn't enough, when using glib as
subproject and the parent project uses only libgio_dep, and include
<gi18n.h>, it won't find libintl.h because it's in the
include_directories of libglib_dep. Fix that by declaring dependencies
explicitly, which is the right thing to do since glib and gobject are
public dependencies of gio. That reflects what we do for the pkg-config
file as well.
When passing a function to G_IMPLEMENT_INTERFACE, it actually has to
take two arguments. Who knew?
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
Add tests using an object declared with G_DECLARE_FINAL_TYPE, that is derived
from another, declared using G_DECLARE_DERIVABLE_TYPE, and that
thus uses _GLIB_DEFINE_AUTOPTR_CHAINUP to define cleanup functions.
And verify that both g_autoptr(Type) and g_auto(s)list(Type) work
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
An assertion is harder to skip over, and using a g_critical() can give
us a more informative error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/179
This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_object_bind_property() (transfer none) returns a GBinding with an existing internal
reference which is active as long as the "binding" is. This allows to optionally use
the binding without any memory management, as it will remove itself when it is no longer
needed.
There are currently three ways to remove the "binding" and as a result the reference:
1) Either the source or target dies and we get notified by a weakref callback
2) The user unrefs the binding until it is destroyed (which is semi-legal,
but worked and is used in the test suite)
3) The user calls g_binding_unbind()
In case (3) the problem was that it always calls unref even if the "binding" is already
gone, leading to crashes when called from bindings multiple times.
In #1373 and !197 it was noticed that a function always unrefs which would be a
"transfer full" annotation, but the problem here is that it should only remove the
ref when removing the "binding" and the annotation should stay "transfer none".
As a side effect of this fix it is now also possible to call g_binding_unbind() multiple
times where every call after the first is a no-op.
This also adds explicit tests for case (1) and (3) - only case (3) is affected by this change.
Part of runMkenumsWithHeader() was duplicated in test_reproducible(),
and would otherwise need to be duplicated again in upcoming tests. Many
places duplicated decoding stdout/stderr and checking the exit code.
Introduce a named tuple for the returned fields; and factor out writing
a template file to pass with --template.
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
Several of our tools are installed and are used by other projects to
generate code. However, there is no 'install' when projects use glib
as a subproject.
We need some way for glib to 'provide' these tools so that when some
project uses glib as a subproject, find_program('glib-mkenums') will
transparently return the glib-mkenums we just built.
Starting from Meson 0.46, this can be done with the
`meson.override_find_program()` function.
As a bonus, the Meson GNOME module will also use these
'overriden'/'provided' programs instead of looking for them in PATH.
PEP8 says that:
"Comparisons to singletons like None should always be done with is or
is not, never the equality operators."
glib uses a mix of "== None" and "is None". This patch changes all
cases to the latter.
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.
Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.
Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
Switch the check which tests whether the object has been finalised from
being a use-after-free, to using a weak pointer which is nullified on
finalisation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If some other per value option was present than 'skip' or 'nick' then
a KeyError would occur. Ignoring such options matches the behaviour of
the old, Perl-based glib-mkenums.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
https://gitlab.gnome.org/GNOME/glib/issues/1360
This makes them a bit more unique (and, crucially, in the g_* namespace)
to avoid shadowing collisions with calling code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/258
It's been 4 years and 8 development cycles since we introduced
G_ADD_PRIVATE and offset-based private data access. It is now
time to finally deprecate the old mechanism.
Closes: #699
Meson has the ability to classify tests according to "suites", a list of
tags. This is especially useful when we want to run specific sets of
tests — e.g. only GLib's tests — instead of the whole test suite. It
also allows us to classify special tests, like "slow" ones, so that we
can only run them when needed.
In master, it is already possible to build GLib using Visual Studio
using Meson[1] for some time, so we should focus on maintaining only the
Meson build files for building GLib with Visual Studio.
[1]: There are caveats when building with Visual Studio 2008, namely
that one needs to use the mt command to embed the manifests that
are generated with the .exe/DLLs, for all builds, and that in the
case where the compilation hangs on Visual Studio 2008 x64, as a
workaround, should stop the build by terminating all cl.exe tasks
and change the compiler optimization flag from /O2 (full speed) to
/O1 (optimize for size), due to compiler optimization issues.
It's mostly not used anymore and doesn't do what it says it does.
The docs state that it affects GList, GSList, GNode, GMemChunks, GSignal,
GType n_preallocs and GBSearchArray while:
* GList, GSList and GNode use GSlice and are not affected
* GMemChunks is gone
* GType npreallocs is ignored
It also states that it can be used to force the usage of g_malloc/g_free,
which is handled by G_SLICE=always-malloc now.
The only places where it's used is in signal handling through GBSearchArray
and in GValueArray (deprecated). Since it's unlikely that anyone wants to
reduce allocation sizes just for those cases remove the build option.
valgrind.h is a verbatim copy taken from Valgrind project. Previously
that file had local changes that got dropped by last update. To avoid
regressing again, do not edit valgrind.h anymore and instead add a
gvalgrind.h wrapper that gets included instead.
This fix 2 errors:
- uintptr_t is not defined when including valgrind.h on mingw.
- MSVC compiler is not supported on amd64-Win64 platform.
The timer tests expect that a small value for sleep does not result in
no sleep at all. Round up to the next millisecond to bring it more in line
with other platforms.
This fixes the glib/timer tests.
This makes the 'threadtests' time out since that uses small usleeps a lot and
until now didn't wait at all, but now always waits a msec. Reduce the amount
of tests done on Windows to get the runtime down to something reasonable again.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
On non-glibc platforms gettext is provided by extra libintl dependency.
We wrongly thought libintl is an internal dependency and applications
needs to explicitly link on it, but turns out that breaks many
applications and with autotools the .pc generated actually has -lintl in
public "Libs:".
https://bugzilla.gnome.org/show_bug.cgi?id=796085
Do not add support for its subtypes, since all their constructors return
GParamSpec*, and g_param_spec_unref() takes a GParamSpec* rather than a
gpointer — adding G_DEFINE_AUTOPTR_CLEANUP_FUNC() for subtypes of
GParamSpec results in compiler warnings about mismatched parameter
types (GParamSpecBoolean* vs GParamSpec*, for example).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=796139
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
The -fstack-protector-strong used in many distributions by default has a
rather drastic slowdown of the fast path in generated _get_type()
functions using G_DEFINE_* macros. The amount can vary by architecture,
GCC version, and compiler flags.
To work around this, and ensure a higher probability that our fast-path
will match what we had previously, we need to break out the slow-path
(registering the type) into a secondary function that is not a candidate
for inlining.
This ensures that the common case (type registered, return the GType id)
is the hot path and handled in the prologue of the generated assembly even
when -fstack-protector-strong is enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=795180
The existing implementation was completely incorrect (despite the fix in
commit 566e64a66) — it always compared GVariants by pointer, rather than
by value.
Reimplement it to compare them by value where possible, depending on
their type. The core of this implementation is g_variant_compare(). See
the documentation and tests for further details of the new sort order.
This adds documentation and tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795735
This was causing g_param_value_defaults to return 1
for GVariant values even when the value is clearly
different from the default.
This was showing up as gtk-builder-tool stripping
non-default values for GtkActionable::action-target
from ui files.
It was previously a copy–paste of G_VALUE_COLLECT, which is wrong,
because it’s the inverse function of G_VALUE_COLLECT. Document that, so
the whole thing is a little less confusing (but by no means perfect).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
The critical omission from the GClosure documentation is that you need
to call g_closure_set_marshal() when implementing a custom GClosure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
glib-genmarshal shows redundant "time" warning message against combination with --header and --body option.
Before:
WARNING: Using --header and --body at the same time time is deprecated; use --body --prototypes instead
After:
WARNING: Using --header and --body at the same time is deprecated; use --body --prototypes instead
https://bugzilla.gnome.org/show_bug.cgi?id=795429
Signed-off-by: Kentaro Hayashi <hayashi@clear-code.com>
On gcc 4.7, we got the following error:
i686-nptl-linux-gnu-gcc --version
> i686-nptl-linux-gnu-gcc (crosstool-NG 1.20.0) 4.7.4
> $ echo '#include <glib-object.h>' | i686-nptl-linux-gnu-gcc -x c -I
staging/usr/include/glib-2.0 -I staging/usr/lib/glib-2.0/include -Wall
-Werror -c - -o /tmp/foo.o
> In file included from
staging/usr/include/glib-2.0/gobject/gbinding.h:29:0,
> from staging/usr/include/glib-2.0/glib-object.h:23,
> from <stdin>:1:
> staging/usr/include/glib-2.0/gobject/gobject.h: In function
'g_set_object':
> staging/usr/include/glib-2.0/gobject/gobject.h:725:5: error: value
computed is not used [-Werror=unused-value]
> cc1: all warnings being treated as errors
This error has been added by commit 3fae39a5d7
So enable the new g_set_object definition only if gcc >= 4.8
Fixes:
- http://autobuild.buildroot.net/results/b29a2f868438a2210873ea72f491db63175848be
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795138
There is no transfer annotation that can express transfer semantics of
g_object_new_with_properties in general. When GInitiallyUnowned object
is constructed the introspection data will be incorrect.
Mark it with skip annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=795025
Previously we were only detecting typedef\*senum\s*\{, which does not
handle the case where there is an entifier for the enum itself but
not the typedef. glib-mkenums would then attempt to read the next line
looking for a matching {, but in vain.
https://bugzilla.gnome.org/show_bug.cgi?id=794506
It’s defined in gutils.h, but various users of GLib might not have
access to that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
https://bugzilla.gnome.org/show_bug.cgi?id=793272
The *_init() functions have prototypes incompatible with *InitFunc types they
are being cast to. This upsets GCC 8's -Wcast-function-type that's enabled by
default with -Wextra.
Let's not have the public header files emit a warning and neutralize it by
doing a void(*)(void) cast first.
https://bugzilla.gnome.org/show_bug.cgi?id=793272
It's not possible to subclass GValue, and by always explicitly casting
here it is easy to write broken code (e.g. passing a GValue**) without
the compiler warning about that.
By not casting, the compiler will error out if anything but a GValue* is
passed here.
https://bugzilla.gnome.org/show_bug.cgi?id=793186
gtk-doc doesn’t support them any more since it was ported to Markdown,
so they end up appearing in the generated documentation, which isn’t
great.
Mostly, they were used to split up things invisibly, which we can do in
other ways.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Properly define GLIB/GOBJECT_STATIC_COMPILATION when static build is enabled.
Use library() instead of shared_library() to allow selecting static builds.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
This makes easier to write a module that can be both dynamic and static.
It will allow to statically build modules from glib-networking, for
example.
A module can rename its g_io_module_load() function to
g_io_<modulename>_load(), and then an application which links statically
against that module can call g_io_<modulename>_load(NULL) to register
types and extension points from the module. If a module is loaded
dynamically, its load() function will continue to be called with a
non-NULL GIOModule instance.
https://bugzilla.gnome.org/show_bug.cgi?id=684282
This is for destroying resources needed by transformations. But the user
may not need any such resources. Make it obvious that, instead of having
to point to a no-op function, @notify is checked and not called if NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=792098
Weak-pointers are currently lacking g_set_object() & g_clear_object()
helpers equivalent. New functions (and macros, both are provided) are
convenient in many case, especially for the property's notify-on-set
pattern:
if (g_set_weak_pointer (...))
g_object_notify (...)
Inspired by Christian Hergert's original implementation for
gnome-builder.
https://bugzilla.gnome.org/show_bug.cgi?id=749527
Conceptually, these functions clearly ought to be fine for a const
structure. This avoids _G_TYPE_CVH (the implementation of
G_TYPE_CHECK_VALUE_TYPE, G_VALUE_HOLDS, G_VALUE_HOLDS_BOXED etc.)
needing to cast to a mutable GValue, which causes
G_VALUE_HOLDS (cv, type) to issue warnings under gcc -Wcast-qual if
cv is a const GValue *.
https://bugzilla.gnome.org/show_bug.cgi?id=734479
Some source files aren't valid utf-8 containing for example
iso8859-1 accented characters in author's names.
Replace invalid data with a replacement '?' character and print a
warning to keep things working.
Based on a patch from Christoph Reiter in
https://bugzilla.gnome.org/show_bug.cgi?id=785113#c20
The type propagation breaks the GRefPtr.h class in WebKitGTK, and in
any case existing C++ code calling the C API will need to perform an
explicit cast, as there's no automatic promotion of pointer types to
and from void*.
Tested-by: GNOME Continuous
https://bugzilla.gnome.org/show_bug.cgi?id=790697
When compiling code that includes gobject.h using GCC with the ISO
standard, the `typeof` keyword is disabled, as it's a GCC extension.
The GCC documentation recommends:
> If you are writing a header file that must work when included in
> ISO C programs, write __typeof__ instead of typeof.
Which is precisely what we're going to do.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790697
Currently, g_object_ref() and g_object_ref_sink() return a
gpointer which can mask issues when assigning to fields or
returning from a function.
To help catch these type of programming errors, we can propagate
the type of the parameter through the function call on GCC
using the typeof() C language extension.
This will cause offending code to have a warning, but will
continue to be source and binary compatible.
This is only enabled when GLIB_VERSION_MAX_ALLOWED is 2.56 or greater.
https://bugzilla.gnome.org/show_bug.cgi?id=790697
Putting a <!-- --> in plural<!-- -->s was an old hack used to fix
linking the symbol with gtk-doc when gtk-doc didn’t know about plural
forms. gtk-doc does now know about plural forms, so the hack can be
removed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's theoretically possible that we could have a case where this would
actually return NULL, but it's difficult to imagine a valid program that
would contain such a case.
Add an explicit assert here to quiet up static analysis.
See the bug for more discussion.
Coverity CID: 1159477
https://bugzilla.gnome.org/show_bug.cgi?id=730296
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
Clarify the licensing of the code generated by the two scripts in a
comment in the header of each generated file. The intention is that the
license of GLib does *not* apply to the generated files; but that they
are subject to the linking restrictions of the LGPL, since they link to
GLib and GLib is licensed under the LGPL. The generated files themselves
are under the license of whatever project they’re generated for.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
We should ensure a stable order when processing the files, regardless of
the order they were submitted on the command line, to increase the
chances of a reproducible build.
The old Perl-based version of glib-mkenums was fixed in commit 8686e430
to do the same.
https://bugzilla.gnome.org/show_bug.cgi?id=691436
The fallback code for providing a default comment template only worked
if a template file was provided. It didn’t work if individual templates
were provided on the command line (and --comment wasn’t).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=788990
They return floating references. The convention established by GVariant
is to annotate these as (transfer none) so that the caller does a
ref+sink on them, rather than just a ref.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=677233
The m4 and bash completion items are usable and relevant
depending on the host system's configuration. So, we check for the
presence of the programs that these items depend on, and only install
them when those programs are found.
For the Valgrind suppression files, we don't install them on Windows as
Valgrind is currently not supported on Windows.
Als fix the path where the GDB helpers are installed, as the path is
incorrectly constructed.
This will fix the "install" stage when building on Visual Studio at
least as there are some post-install steps that are related to them,
which will make use of these programs.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
This was duplicated also in g_object_interface_install_property().
Now, validations specific to classes happen in
validate_and_install_class_property() - specifically, the checks for
the presence of the get_property() and set_property() methods.
https://bugzilla.gnome.org/show_bug.cgi?id=787551
Commit 31ae2c5598 added the C++ guards
around all prototypes, including inside the header file. The header
file, though, already has C++ guards, so while it's harmless to have
them there, it's also unnecessary.
We should only emit C++ guards around the prototypes we include in the
generated source.
Since --header --body has been deprecated and replaced with --body
--prototypes, the generated body is not wrapped with G_{BEGIN,END}_DECLS
any longer. Projects using C++ break due to that. Automatically wrap
prototypes individually in G_{BEGIN,END}_DECLS instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785554
In case of Python 2 and stdout being redirected to a file, sys.stdout.encoding
is None and it defaults ASCII for encoding text.
To match the behaviour of Python 3, which uses the locale encoding also when
redirecting to a file, wrap sys.stdout with a StreamWriter using the
locale encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
Instead of using NamedTemporaryFile, which doesn't take an encoding in Python 2
use mkstemp() to create a file and open it with io.open(), with a proper
encoding set.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
On Windows open() defaults to ANSI and on Python 2 it doesn't take
an encoding. Use io.open() instead which provides the same interface
on both Python versions.
https://bugzilla.gnome.org/show_bug.cgi?id=785113
The Meson build has fallen a bit behind the Autotools one, when it comes
to the internally built tools like glib-mkenums and glib-genmarshals.
We don't need to generate gmarshal.strings any more, and since the
glib-genmarshal tool is now written in Python it can also be used when
cross-compiling, and without indirection, just like we use glib-mkenums.
We can also coalesce various rules into a simple array iteration, with
minimal changes to glib-mkenums, thus making the build a bit more
resilient and without unnecessary duplication.
The old glib-mkenums was more forgiving, and simply ignored any files it
could not find.
We're going to print a warning, as in the future we may want to allow
more strictness.
This is a bit of a hack to maintain some semblance of backward
compatibility with the old, Perl-based glib-mkenums. The old tool had an
implicit ordering on the arguments and templates; each argument was
parsed in order, and all the strings appended. This allowed developers
to write:
glib-mkenums \
--fhead ... \
--template a-template-file.c.in \
--ftail ...
And have the fhead be prepended to the file-head stanza in the template,
as well as the ftail be appended to the file-tail stanza in the
template. Short of throwing away ArgumentParser and going over
sys.argv[] element by element, we can simulate that behaviour by
ensuring some ordering in how we build the template strings:
- the head stanzas are always prepended to the template
- the prod stanzas are always appended to the template
- the tail stanzas are always appended to the template
Within each instance of the command line argument, we append each value
to the array in the order in which it appears on the command line.
This change fixes the libqmi build.
Some of the arguments that affect the generated result in glib-mkenums
can be used multiple times, to avoid embedding unnecessary newlines in
their values.
This change fixes the NetworkManager build.
When using the `--header --body` compatibility mode, we need to emit
things we generally define in the header, such as the aliases for
standard marshallers, and aliases for deprecated tokens.
This fixes dbus-binding-tool, which is using `--header --body` and
deprecated tokens.
See: https://bugs.freedesktop.org/show_bug.cgi?id=101799
Fixes get_type function generation for:
- GMountMountFlags
- GDriveStartFlags
- GResourceLookupFlags
- GSocketMsgFlags
- GTlsDatabaseVerifyFlags
- GTestDBusFlags
which were registered as enum types before, which broke
some unit tests.
Problem is that the flags annotation has no value, so
options.get('flags') would always return None even if
it was present.
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This reduces the build-time dependencies of glib to only Python 3,
Meson, and git. Git is also optional if you provide a tarball in
which the subproject directories already exist.
The Python port was done by Jussi Pakkanen on bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=779332
This version contains some fixes from that and also changes all
instances of `@` to `\u0040` because Meson does not yet provide a
configure_file() mode that ignores unknown @MACRO@ values.
This is a stub-only library that can be used while building against
MSVC and contains no i18n machinery at all.
The dependencies added indirectly use the libintl.h header, and when
built as a subproject, the header won't be in a path known the
pre-processor.
Don't use it project-wide for building everything. Otherwise
symbols for shared modules won't be exposed, e.g. in the
resourceplugin used by the gio resource unit test.
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.
Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll and
glib-2.0-0.dll on Windows with MSVC.
Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.
Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
We're in the process or rewriting other tools in Python to reduce the
number of dependencies of GLib.
Additionally, making glib-genmarshal a Python script reduces the
complexity when cross-compiling, as we don't need a native build to
generate the marshallers.
https://bugzilla.gnome.org/show_bug.cgi?id=784528
It is possible, when using GTK-Doc, to mark sections of an enumeration
type as "private": the values are there, but they are not documented,
and GTK-Doc won't complain about missing symbols:
typedef enum {
/*< private >*/
MY_FOO_PRIVATE,
/*< public >*/
MY_FOO_VALUE_A,
MY_FOO_VALUE_B,
/*< private >*/
MY_FOO_VALUE_C,
MY_FOO_VALUE_D
} MyFooValue;
The glib-mkenums parser also allows skipping enumeration values, using a
slightly different syntax:
typedef enum P
MY_BAR_PRIVATE, /*< skip >*/
MY_BAR_VALUE_A,
MY_BAR_VALUE_B
} MyBarValue;
The annotation must sit on the same line as the enumeration value.
Both GTK-Doc and glib-mkenum use the same trigraph syntax, but slightly
different keys. This makes combining them slightly redundant, but
feasible.
All would be well and good, except that glib-mkenum will generate a
warning for lines it does not understand — and that includes the GTK-Doc
annotation trigraph, which, when confronted with the MyFooValue
enumeration above, will result in a warning like:
glib-mkenums: myfoo.h:2: Failed to parse ` /*< private >*/ '
glib-mkenums: myfoo.h:5: Failed to parse ` /*< public >*/ '
glib-mkenums: myfoo.h:9: Failed to parse ` /*< private >*/ '
Of course, we could make glib-mkenum ignore any trigraph comment on a
stand alone line, but it would probably be better to ensure that both
glib-mkenums and gtk-doc behave consistently with each other, and
especially with the maintainer's intent of hiding some values from the
user, and reserving them for internal use.
So we should ensure that glib-mkenums automatically skips all the
enumeration values after a "private" flag has been set, until it reaches
a "public" stanza.
https://bugzilla.gnome.org/show_bug.cgi?id=782162
This way code that does not manually include the generated marshallers
header and wishes to build with `-Wmissing-prototypes` will not generate
a compiler warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781755
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
This is going to be checked again by g_object_new_with_properties()
and g_object_new_valist() anyway, so might just as well leave it
to those functions to do the check and only do it once. It doesn't
matter which function emits the critical warning in the end either,
as one has to look at a stack trace to find out what code triggered
it in any case.
https://bugzilla.gnome.org/show_bug.cgi?id=780908
g_object_newv uses a GParameter as argument. Since GParameter
is deprecated due to this type is not introspectible,
g_object_newv is deprecated now.
https://bugzilla.gnome.org/show_bug.cgi?id=709865
g_object_new_with_properties is an alternative to g_object_newv.
The last one, takes an array of GParameter. However, GParameter
is a rarely used type and this type is not introspectible, so
it will not work properly in bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=709865
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
