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
