If `right` and `left` are both near `G_MAXUINT`, it’s possible for the
addition to overflow, even if the eventual result would fit in a
`guint`. Avoid that by operating on the difference instead.
The difference is guaranteed to be positive due to the prior `left <=
right` check.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The allocation size was set correctly before, but not the array length,
so the copied array appeared to have zero elements.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
glib/garray.c: In function ‘g_ptr_array_insert’:
glib/garray.c:1522:14: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘guint’ {aka ‘unsigned int’} [-Werror=sign-compare]
if (index_ < rarray->len)
^
../glib.git/glib/garray.c: In function ‘g_ptr_array_maybe_expand’:
../glib.git/glib/garray.c:1172:43: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘gint’ {aka ‘int’} [-Werror=sign-compare]
if G_UNLIKELY ((G_MAXUINT - array->len) < len)
The text about deallocation of GArrays with elements containing
dynamically-allocated memory was confusing. It initially mentioned
clear_func, but later said elements with dynamically allocated memory
"should be freed separately".
Clarify this by using the same structure as g_ptr_array_free —
highlight the need to set a clear_func by consolidating the text about
it in a separate paragraph.
https://gitlab.gnome.org/GNOME/glib/merge_requests/348
We should bail when we detect that adding a number of items to an array
would cause it to overflow. Since we can't change to using gsize for ABI
reasons we should protect the integrity of the process even if that means
crashing.
When over-allocating by inserting values off the end of an array, maybe
expand the array once, rather than twice (once for setting the size and
once for appending the values).
Suggestion by Peter Bloomfield (@peterb) as a follow-up to #1374.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, g_array_insert_vals() would crash if called with an index
off the end of the array. This is inconsistent with the behaviour of
other methods (like g_array_set_size()), which will expand the array as
necessary.
Modify g_array_insert_vals() to expand the array as necessary. New array
elements will be cleared to zero if the GArray was constructed with
(clear_ == TRUE).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
They do both accept NULL value arrays, but only if the number of
elements in the value array is zero. Fix the annotations and mention
this in the documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795975
These make it easy to steal elements from pointer arrays without having
the array’s GDestroyNotify called on them, similarly to what’s possible
with g_hash_table_steal().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
If using g_ptr_array_remove*() with a non-NULL GDestroyNotify function,
the value returned will probably be freed memory (depending on what the
GDestroyNotify) function actually does. Warn about that in the
documentation. We can’t just unconditionally return NULL in these cases,
though, since the user might have set the GDestroyNotify to a nifty
function which doesn’t actually free the element; so returning it might
still be valid and useful.
Also add missing (nullable) annotations to that documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
They were almost identically the same. This introduces no functional
changes, but will help with upcoming additions to GPtrArray.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=795376
And warn in other parts of the code if the caller attempts
to change the array bounds during destruction, this is not
a valid operation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to not use inline
for loop declarations, since we can’t support them in GLib at the
moment.)
https://bugzilla.gnome.org/show_bug.cgi?id=769064
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
Partially based on telepathy-glib’s tp_g_ptr_array_contains(), and a
patch by Xavier Claessens <xavier.claessens@collabora.co.uk>.
Test cases included.
https://bugzilla.gnome.org/show_bug.cgi?id=698064
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.
Previously, calling g_array_remove_range(array, 0, array->len) on an
empty array would result in a precondition failure in
g_array_remove_range(), as the given start index (0), was not strictly
less than the array length (0).
Allow the index to equal the array length, so that zero elements can be
removed from any array. A subsequent check makes sure that the array
length is not overflowed by the index + length.
https://bugzilla.gnome.org/show_bug.cgi?id=763339
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
Internal allocation size (array->alloc) was being kept to 0 when a new
GByteArray was created from an already existing heap-allocated buffer.
Among other things, this was making g_byte_array_set_size() fully clear all
the buffer contents (not just the newly allocated memory) when
G_DEBUG=gc-friendly was being used...
if (G_UNLIKELY (g_mem_gc_friendly))
memset (array->data + array->alloc, 0, want_alloc - array->alloc);
https://bugzilla.gnome.org/show_bug.cgi?id=738170
For the GPtrArray example, several variables declared on the same line
is harder to read and to work with (to move, remove or comment a single
variable declaration).
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
g_array_remove_range and g_byte_array_remove_range return
a pointer to the array, g_ptr_array_remove_range returns
void. Since it is pretty harmless, make it return the array
too.
https://bugzilla.gnome.org/show_bug.cgi?id=159528
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
Make g_byte_array_new() and g_byte_array_new_take() introspectable by adding
missing transfer annotations to return value.
Covered by tests in PyGObject.
