Because it now handles EINTR. And we should do so. While most people
use Linux, which tries very hard to avoid propagating EINTR back up
into userspace, it can still happen.
https://bugzilla.gnome.org/show_bug.cgi?id=682833
This avoids warnings when creating idiomatic value tables, like:
static const GTypeValueTable _clutter_shader_float_value_table = {
clutter_value_init_shader_float,
clutter_value_free_shader_float,
clutter_value_copy_shader_float,
clutter_value_peek_pointer,
"ip",
clutter_value_collect_shader_float,
"pp",
clutter_value_lcopy_shader_float
};
Because the strings are literals. And, really: nobody should be using
allocated values for the collection and lcopy strings.
https://bugzilla.gnome.org/show_bug.cgi?id=671545
The current note makes it look like the marshaller code generation has
been deprecated in favour of the libffi-based generic marshaller; this
is not the case, so we should probably clarify the point a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=677235
Otherwise we crash with a null-ptr deref in g_object_newv and ever there we
should not return null, as we're saying that object creation will not return
null.
Expand the documentation for g_object_[freeze|thaw]_notify() to explain that
it deduplicates “notify” signals emitted by frozen objects, so that at most
one signal is emitted per property.
https://bugzilla.gnome.org/show_bug.cgi?id=676937
I didn't do this comprehensively, since there's a lot of it, mainly
due to the GDBus object manager stuff, but anyone trying to use
that would fail fast due to lack of the gdbus code generator.
My main goal was to get API additions to existing classes like
g_data_input_stream_read_line_utf8(), as well as the lower level new
API like glib-unix.h.
https://bugzilla.gnome.org/show_bug.cgi?id=676816
Commit f084b60377 incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am. In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Tested-by: Rico Tzschichholz <ricotz@t-online.de>
https://bugzilla.gnome.org/show_bug.cgi?id=667806
This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
If the optimization is used for only having one closure handling a
signal emission, then hooks will not be run, so it should be disabled
when an emission hook is added.
https://bugzilla.gnome.org/show_bug.cgi?id=671918
The trace of the signal emission of the was calculating the instance
type after the instance was unrefed. Fix this by keeping the instance type around.
The ability to cross-compile glib got broken after the
merge of the 'signal-performance' branch as the assumption
was made that the generated glib-genmarshal can be executed
on the host (which isn't valid when cross-compiling).
Fixed this by using the just-built glib-genmarshal for normal
compilations and the native (host) glib-genmarshal when doing a
cross-compilation as was also done in several other areas of GLib
Tested for host=x86_64-unknown-linux-gnu, target=x86_64-unknown-linux-gnu
and host=x86_64-unknown-linux-gnu, target=i686-w64-mingw32
https://bugzilla.gnome.org/show_bug.cgi?id=671676
In the code generation portion, va_copy() is not universally available,
so use the existing G_VA_COPY macro that in turn calls va_copy() if it
is available or call an appropriate emulation otherwise.
va_vopy() is not universally available in all compilers, so make use of
the existing G_VA_COPY macro which either calls va_copy() if it is
available, or emulates it if otherwise.
When there is only one closure handling a signal emission and
it doesn't have a bunch of complicated features enabled we
can short circuit the va_args collection into GValues and call the
callback via the va_marshaller directly.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
If the signal argumment types matches a built in standard
marshaller we use the va_marshaller for that, and also the
normal marshaller if NULL was specified (as its faster than
the generic one).
This lets you set a va_marshaller on your signal which will be
propagated to all closures for the signal. Also, automatically
uses the generica va_marshaller if you specify a NULL c_marshaller.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
This means we're not abusing the notifiers for meta_marshallres,
and we're able to later cleanly add other fields to GClosure.
We still have to leave the ABI intact for the GClosure->meta_marshal
bit, as old G_CLOSURE_N_NOTIFIERS macro instances still accesses it.
However, we always set it to zero to keep those macros working.
https://bugzilla.gnome.org/show_bug.cgi?id=661140
Transforming a GValue holding flags from a GFlagsValue set that includes the 0
value (no flag bits set) into a string would loop until exhausting all the
available memory.
https://bugzilla.gnome.org/show_bug.cgi?id=670557
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
Given
typedef enum MyFoo MyFoo;
glib-mkenums would get confused, not notice the ";", and then keep
skipping lines until it found one that started with a "{", possibly
even going into the next file.
Fix it to just ignore those lines instead (and also, to error out if
it hits eof while parsing an enum).
https://bugzilla.gnome.org/show_bug.cgi?id=669595
The GValueArray type was added in a time, during the Jurassic era or so,
when GArray did not have a representable GType. The GValueArray API has
various issues as well:
- it doesn't match the other GLib array types;
- it is not reference counted;
- the structure is fully exposed on the stack, so it cannot be
extended to add reference counting;
- it cannot be forcibly resized.
The nice thing is that now we have a GArray type that can replace in
full GValueArray, so we can deprecate the latter, and reduce the
complexity in GLib, application code, and bindings.
https://bugzilla.gnome.org/show_bug.cgi?id=667228
... 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?
Transparent access to a weak pointer from the thread performing the
weak -> strong conversion is incompatible with thread-safety: that
thread will have to do something special. This is GNOME#548954.
https://bugzilla.gnome.org/show_bug.cgi?id=548954
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
We were previously preventing implementations of an interface from
specifying G_PARAM_CONSTRUCT for a property of that interface if the
interface didn't specify it itself (or was readonly).
This is something that should only interest the implementation, so we
remove this restriction.
This allows 6 new possible override scenarios:
- writable -> writable/construct
- writable -> readwrite/construct
- readwrite -> readwrite/construct
- writable/construct-only -> writable/construct
- writable/construct-only -> readwrite/construct
- readwrite/construct-only -> readwrite/construct
and we update the testcase to reflect this.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Add a testcase to check all possibilities for overriding a property
specified on an interface from an implementation of that interface,
changing the type and flags.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Change the order of the checks so that we hear about the 'biggest'
problem first. Also, stop reporting problems after we report the first
one for a particular property.
Add some comments.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
The property override typecheck was meant to enforce the type on the
overriding property being exactly equal to the type on the interface
property. Instead, g_type_is_a() was incorrectly used.
We could try to enforce equality, but if a property is read-only then it
should be possible for the implementation to type the property with any
subtype of the type specified on the interface (because returning a more
specific type will still satisfy the interface). Likewise, if the
property is write-only then it should be possible for the implementation
to type the property with any supertype.
We implement the check this way.
https://bugzilla.gnome.org/show_bug.cgi?id=666616
Simplify some of the logic in this function.
1) Simplify flag checks as per Colin's suggestions in
https://bugzilla.gnome.org/show_bug.cgi?id=605667
2) Don't repeatedly recheck if class_pspec is NULL.
GObject enforces the following restrictions on property overrides:
- must only add abilities: if the parent class supports
readability/writability then the subclass must also support them.
Subclasses are free to add readability/writability.
- must not add additional restrictions: if the parent class doesn't
have construct/construct-only restrictions then the subclass must
not add them. Subclasses are free to remove restrictions.
The problem with the previous implementation is that the check against
adding construct/construct-only restrictions was being done even if the
property was not previously writable. As an example:
"readable" and "writable only on construct"
was considered as being more restrictive than
"read only".
This patch tweaks the check to allow the addition of
construct/construct-only restrictions for properties that were
previously read-only and are now being made writable.
https://bugzilla.gnome.org/show_bug.cgi?id=666615
First, some ARM systems are not fast enough to meet the 30 second
deadline in gwakeuptest.c, so increase that to 60.
Second, we have some signed/unsigned woes in the gparam transform tests.
These don't really matter, since it's test code, but they do obscure
real leaks in the library.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=666115
Acked-by: Matthias Clasen <mclasen@redhat.com>
Either g_type_register_static_simple (used by G_DEFINE_TYPE_EXTENDED)
and G_IMPLEMENT_INTERFACE use automatic variables for GTypeInfo and
GInterfaceInfo structs, while tutorials and source code often use
static variables. This commit consistently adopts the former method.
https://bugzilla.gnome.org/show_bug.cgi?id=600161
* Represents an immutable reference counted block of memory.
* This is basically the internal glib GBuffer structure exposed,
renamed, and with some additional capabilities.
* The GBytes name comes from python3's immutable 'bytes' type
* GBytes can be safely used as keys in hash tables, and have
functions for doing so: g_bytes_hash, g_bytes_equal
* GByteArray is a mutable form of GBytes, and vice versa. There
are functions for converting from one to the other efficiently:
g_bytes_unref_to_array() and g_byte_array_free_to_bytes()
* Adds g_byte_array_new_take() to support above functions
https://bugzilla.gnome.org/show_bug.cgi?id=663291
When the 'conditional' parameter is TRUE, the queue will only be frozen
(ie: have its freeze count increase by one) if it is already frozen.
This will allow us to avoid a freeze-notify-thaw in the case that we
just want to notify on a single property.
Another approach may have been to add an is_frozen() type call and avoid
even increasing the freeze count at all in this case. Unfortunately,
I'm not totally sure what is the exact expected semantics of
simultaneous notifications in multiple threads and this may interact
badly with someone freezing or thawing in between our check and
emission.
Lift the check-if-READABLE and redirect-target logic from out of
g_object_notify_queue_add() into its own function, get_notify_pspec().
Use that function at the site of our two calls to
g_object_notify_queue_add().
This was done as a separate file before, and #include brought it into
gobject.c. That's a bit mad, so stop doing that.
Unfortunately, the insanity steps up a level: gobjectnotifyqueue.c is
installed in the public include dir, so we can't just get rid of it
entirely.
Similar to G_PARAM_DEPRECATED. It will warn only for users of the
signals, so a signal can still be emited without warning, for
compatibility reasons.
Apparently, there is no way user flags could have been used before,
so that shouldn't break anyone.
https://bugzilla.gnome.org/show_bug.cgi?id=663581
Instead of:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use '((GType) ((21) << (2)))' instead [-Wdeprecated-declarations]
show:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use ''G_VARIANT_GET_TYPE'' instead [-Wdeprecated-declarations]
Also, document the macro-expansion problem in the
G_GNUC_DEPRECATED_FOR docs
Allow passing --identifier-prefix and --symbol-prefix to glib-mkenums,
with the same meanings as in g-ir-scanner, to allow fixing up the enum
name parsing globally rather than needing to add a /<* *>/ override to
each enum.
https://bugzilla.gnome.org/show_bug.cgi?id=661797
This was used as an optimisation for the macro hackery that used to live
in gthread.h. If a particular library or program knew that it could
rely on thread support being enabled, it would allow for static
evaluation of conditionals in some of those macros.
Since the macros are dead and thread support is now always-on, we can
get rid of this bit of legacy.
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().
Change the wording in the docs. Clarify expectations for
(deprecated) g_thread_create().
enums are stored in v_long but need to be marshalled as signed
integers. On platforms where int is 32 bits, taking the
address of v_long resulted in the wrong 32 bits being marshalled.
So we need to stuff the enum's int-sized value to a temporary
int-sized variable and marshall that instead.
Second, on return, libffi actually returns a pointer to a value
that's sized according to platform conventions, not according to
what the caller requested. ie if ffi_type_sint was requested, the
value can still be a 64-bit sign-extended long on a 64-bit
architecture like PPC64, thus the caller cannot simply cast
the return value as a pointer to the desired type, but must cast
as a pointer to an integral type and then cast to the desired
type to remove any sign extension complications.
For more information on how to correctly handle libffi return
values, see the following bug, specifically comment 35:
https://bugzilla.redhat.com/show_bug.cgi?id=736489
"For 64-bit ABIs that extend integral returns types to 64-bits, libffi always
returns full 64-bit values that you can truncate in the calling code. It's
just the way it is has always been. Please don't change libffi. I'll document
this clearly for the next version (perhaps there is a mention of this, I
haven't looked yet).
The same is true for returning 8-bit values, for instance, on 32-bit systems.
All ABIs extend those results to the full 32-bits so you need to provide a
properly aligned buffer that's big enough to hold the result."
https://bugzilla.gnome.org/show_bug.cgi?id=659881
These were the last users of the dynamic allocation API.
Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).
https://bugzilla.gnome.org/show_bug.cgi?id=660739
It's impossible to check this if the library user is using
g_type_register_static, but in that case their compiler should hopefully
warn about the truncation. This fixes it for G_DEFINE_TYPE and friends,
at least.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=659916
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
Some links were broken due to typos, because functionality was removed
in GLib 2.0 or for various other reasons. Fix up as many of them as is
reasonable.
The implementation of GValue is not public or documented. When
allocated on the stack, initializing a GValue is usually done as
documented with:
GValue value = { 0, };
There is lot code around (including WebKit) that added all the missing
fields, resulting in this ugly and non-obvious:
GValue value = { 0, { { 0 } } };
However, this doesn't play nice with -Wmissing-field-initializers for
example. Thus, G_VALUE_INIT.
http://bugzilla.gnome.org/show_bug.cgi?id=654793http://bugzilla.gnome.org/show_bug.cgi?id=577231
In an attempt to avoid some potential future abuses of the GParamSpec
API, qualify the 'name' field of the structure as 'const' and add a
comment noting that it is an interned string.
This is a theoretical API break, but it will only ever result in
warnings -- and even then, only if you were already doing something
questionable.
Clean up some of the warnings that were caused internally in gparam.c
from these changes.
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
The -e parameter to echo isn't recognized by echo in POSIX sh,
but isn't needed when no escaped characters need to be
interpreted.
This fixes building glib with a mingw cross compiler on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=654085
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
The check for _MSC_VER here is not necessary here because:
-One cannot compile GLib out-of-the-box with VS 2003 (let alone VS6
or earlier) since GLib 2.22.4 or so.
-This code compiles fine with the currently-supported VS versions
(2008/2010) without the error mentioned in the comments.
This will close Bug 652002.
Based on a patch by Giovanni Campagna <gcampagna@src.gnome.org>
From discussion, GVariantIter is not useful for bindings, but
GVariantBuilder may be.
https://bugzilla.gnome.org/show_bug.cgi?id=646635
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
The grouping in files/headers is not used anymore, and
the function attributes neither. Adapt abicheck scripts
and .def file generation rules accordingly.
The hash table used exclusively for looking up types by name used to map
quarks => types. But we can easily make it map strings => types, which
avoids the quark lookup. And that in trun avoids taking a lock and
consulting another hash table. So this change should make
g_type_from_name() roughly twice as fast.
In some cases, signal arguments have to be collected, even if there are i
no signal handlers connected (e.g. for GVariant parameters, where collection
consumes a floating variant).
Based on a patch by Christian Persch.
Bug #643624.
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
I couldn't tell from reading the documentation whether I had to pass in
an uninitialized value, or a value initialized to the exact type, or
something else. It turns out (from reading the source) that you have to
pass in an initialized value, but you can use any type to which the
property's actual type can be transformed.
So, let's document this.
The code section guarded with toggle_refs_mutex includes a call to
g_object_unref(), which may call toggle_refs_notify(). As the latter
tries to acquire the same mutex, glib locks up.
https://bugzilla.gnome.org/show_bug.cgi?id=632884
Previously, dumping a GValue holding a GStrv just yielded "((GStrv *)
0xDEADBEEF)". I think it'd be more useful to dump a Python list-style
representation of the GStrv's contents, if it's not NULL.
Fixes: <https://bugzilla.gnome.org/show_bug.cgi?id=629192>
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
The gdatasetprivate.h header includes gatomic.h directly. It all works
well in GLib, but inside GObject it will trigger the single inclusion
guard.
Since this is a private header, and it's kind of a special case, one way
to fix it is to declare GLIB_COMPILATION around it and fool the single
inclusion guard in gatomic.h into thinking we're compiling GLib and not
GObject.
g_object_class_list_properties tries to sort the returned list of
paramspecs by 'type depth' and param_id. But all the overridden
interface properties have a param_id of 0, so they come out in
a random order.
Bug 628253.
The previous code dedup'd when thawing and threw nasty warnings your way
if you notified too often. This can now easily be avoided.
Performance should be roughly identical, as both are O(n²).
