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.
