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
