If a class implements GAsyncInitable, and its parent also implements
it, then the subclass needs to call its parent's init_async() before
running its own. This was made more complicated by the fact that the
default init_finish() behavior was handled by the wrapper method
(which can't be used when making the super call) rather than the
default implementation itself. Fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=667375
Neither of those usages is valid, but there's a lot of use of 0 as a
domain "in the wild", so we can't g_return_if_fail yet.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=660371
This should help getting static builds working on mingw.
Based on a patch by Volker Grabsch, bug 619126.
At the same time, drop the unnecessary GLIB_RT_LIBS variable;
we are already adding -lrt to G_THREAD_LIBS.
Adding a child source to an already-attached parent source would
crash, because we were passing the parent's context when setting the
child's priority.
When the flags enum only has the default NONE = 0 entry, glib-mkenums
creates an enum type for it, not a flags type. Add an annotation to the
enum to ensure the correct GType is created.
Bug #667938.
This is particular useful for:
g_array_new (sizeof (MyStruct), FALSE, FALSE);
because the correct incantation is
g_array_new (FALSE, FALSE, sizeof (MyStruct));
and these warnings will trigger in the first situation.
... and g_value_get_gtype(). G_TYPE_GTYPE is a pointer type, so it's
values should use the v_pointer member. This is especially true, because
the value collectors from varargs in gvaluecollector.h use that, too.
This should only cause issues when sizeof(glong) != sizeof(gpointer),
and I'm not aware of any such platform. Maybe win64?
GResource is a bundle of files combined into a single binary blog.
The API lets you access the files the resource contains by
using resource paths. You can also register resources with a
global list and access these globally in a merged resource namespace.
The normal way this is used is to link in the resources into your
application/library and have it be automatically registred.
Resources are compiled from an xml description using
glib-compile-resources.
This is only supported on some compilers, so we define G_HAS_CONSTRUCTORS
when it is supported. However, when it is supported we guarantee that
both constructors and destructors work, in executables as well as shared
libraries (including runtime unloading of shared libraries).
Usage is a bit unorthodox, as some compilers need to use #pragma to
implement constructors, and #pragma can't be used in macros.
The canonical way to use this:
#ifdef G_DEFINE_CONSTRUCTOR_NEEDS_PRAGMA
#pragma G_DEFINE_CONSTRUCTOR_PRAGMA_ARGS(my_constructor)
#endif
G_DEFINE_CONSTRUCTOR(my_constructor)
static void my_constructor (void)
{
...
#ifdef G_DEFINE_DESTRUCTOR_NEEDS_PRAGMA
#pragma G_DEFINE_DESTRUCTOR_PRAGMA_ARGS(my_destructor)
#endif
G_DEFINE_DESTRUCTOR(my_destructor)
static void my_destructor (void)
{
...
This is implemented by with statfs_buffer.f_bavail (free blocks
for unprivileged users) as a default way to retrieve real free space.
Based on a patch by Marcus Carlson, bug 625751.
