This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some editors automatically remove trailing blank lines, or
automatically add a trailing newline to avoid having a trailing
non-blank line that is not terminated by a newline. To avoid unrelated
whitespace changes when users of such editors contribute to GLib,
let's pre-emptively normalize all files.
Unlike more intrusive whitespace normalization like removing trailing
whitespace from each line, this seems unlikely to cause significant
issues with cherry-picking changes to stable branches.
Implemented by:
find . -name '*.[ch]' -print0 | \
xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g'
Signed-off-by: Simon McVittie <smcv@collabora.com>
There is (at most) a single GType that is instantiable and a
prerequisite for an interface. This function returns that type.
This type is necessary in particular when dealing with GValues because a
GValue contains an instance of a type.
The previous documentation said this:
g_type_add_interface_static:
"Adds the static interface_type to instantiable_type"
g_type_add_interface_dynamic:
"Adds the dynamic interface_type to instantiable_type"
The above suggests that if one is adding a static interface to a dynamic
object, one should use g_type_add_interface_static because the interface
is static, but the code and usage (with the newly added
G_IMPLEMENTS_INTERFACE_DYNAMIC) imply that this is wrong, and that
what matters is whether the *instanciable_type* is dynamic or not.
Hence this patch moves the "static" and "dynamic" words close to
"instantiable_type".
Closes issue #259
These have all been documented as deprecated for a long time, but we’ve
never had a way to programmatically mark them as deprecated. Do that
now.
This is based on the list of deprecations from the reverted commit
80fcb1bc2.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #638
It's been 4 years and 8 development cycles since we introduced
G_ADD_PRIVATE and offset-based private data access. It is now
time to finally deprecate the old mechanism.
Closes: #699
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.
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
glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
historically, DEBUG_CODE(gtype.c) and IF_DEBUG(gobject.c, gsignal.c)
macros are used to support debugging messages about object bookkeeping
and signal emission.
DEBUG_CODE has never been used in gtype.c. IF_DEBUG, when used, must be
accompanied by an extra #ifdef G_ENABLE_DEBUG. this is cumbersome.
this patch add a new macro GOBJECT_IF_DEBUG based on DEBUG_CODE as
a replacement for both DEBUG_CODE and IF_DEBUG.
https://bugzilla.gnome.org/show_bug.cgi?id=729914
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
It seems that VS 2015 optimizes out the constructor on windows,
so it is better to use a DllMain to initialize the library
and keep using a normal constructor on the other platforms.
This research was done by Arnav Singh.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Make it a little easier to find the GType conventions page, which I
guess should be the canonical guide to how to name things.
This adds a brief mention of the valid characters in a type name to the
conventions page.
https://bugzilla.gnome.org/show_bug.cgi?id=743018
Restricting the number of children to be less than 4095 can
be an issue when generating types. This is also an issue for
the Lua bindings as each Lua state will create a new GType each
time the Lua code is executed.
https://bugzilla.gnome.org/show_bug.cgi?id=747882
Add GOBJECT_DEBUG=instance-count which enables internal accounting
of the number of instances of each GType, and g_type_get_instance_count()
to retrieve the result.
https://bugzilla.gnome.org/show_bug.cgi?id=354457
Not all instances have a TypeNode associated (e.g. GstEvent), so lets check if node is available
before trying to use it.
This crash can be easily reproduced by creating an event with gst_event_new_eos and using
G_IS_OBJECT on the event instance.
https://bugzilla.gnome.org/show_bug.cgi?id=733982
A year ago, we tried to remove support for adding interfaces on
already-initialised types. There were problems with the C++ and C#
bindings at the time, so we added exceptions to give them a bit more
time to catch up.
It's already one cycle after when these exceptions were planned to be
removed, so let's take them out now.
https://bugzilla.gnome.org/show_bug.cgi?id=697229
On initialisation, GObject guarantees to zero-fill
class/object/interface structures. Document this so people don’t spend
forever writing:
my_object->priv->some_member = NULL;
my_object->priv->some_other_member = NULL;
https://bugzilla.gnome.org/show_bug.cgi?id=729167
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
g_type_class_add_private() was doing
g_assert (node->data->instance.private_size <= 0xffff);
but that field is a guint16, so the check was a no-op. (Noticed by
clang, but not gcc for some reason.) Fix it to do the math in a gssize
variable and do the bounds checking there before updating the struct
field.
https://bugzilla.gnome.org/show_bug.cgi?id=706888
For static types, it should be possible to register a private data
structure right when we are registering the type, i.e. from the
get_type() implementation. By allowing this, we can take advantage of
the existing type definition macros to cut down the amount of code
necessary (as well as the knowledge baggage) when creating a new type.
The main issue with this new feature is that it cannot be mixed with the
old idiomatic way of adding private instance data by calling a function
in the middle of the class_init() implementation, as that imposes the
additional constraint of initializing the whole type hierarchy in order
to retrieve the offset of the private data in the GTypeInstance
allocation.
For this reason we are going to follow a two-step process; in the first
step, we are going to introduce the new (semi-private) API to register
the intent to add private instance data from within the get_type()
implementation, and hide it behind a macro; at the same time, the
G_DEFINE_TYPE_EXTENDED macro is going to be modified so that it will
register the private instance data if the macro was used, using a new
(semi-private) function as well. Once we have migrated all our code, we
will make the first new function perform the actual private data
registration, and turn the second new function into a no-op. This should
guarantee a transparent migration of existing code to the new idiomatic
form.
https://bugzilla.gnome.org/show_bug.cgi?id=700035
GObject has previously allowed installing properties after class_init
has finished running. This means that you could install some of your
own properties on G_TYPE_OBJECT, for example, although they wouldn't
have worked properly.
A previous patch asserted that this was not true and we had to revert it
because it broke the shell. Instead of reverting, we should have used a
critical, so do that now.
Complaints go to this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=698614
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
Since instance private data is now always at a constant offset to the
instance pointer, we can add an accessor for it that doesn't also
require an instance.
The idea is that classes can call this from their class_init and store
it in a file-scoped static variable and use that to find their private
data on instances very quickly, without a priv pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=698056
