Unify the creation of GPtrArray.
Maybe we will add yet another constructor for creating %NULL terminated
arrays. Unify the constructors by adding an internal helper method.
The alternative instead of adding a ptr_array_new() helper, would be to
let everybody call g_ptr_array_full(). For no strong reasons, choose
this approach because the compiler is more eager to inline the static
helper as it would inlining g_ptr_array_full().
g_ptr_array_extend_and_steal() leaves the GPtrArray in an invalid state,
so if you would try to append another pointer, it leads to a crash.
Also adjust the test case so that it would result in the crash (without
the fix).
Fixes: 0675703af0 ('Adding g_ptr_array_extend_and_steal() function to glib/garray.c')
Spotted by Mohammed Sadiq. `g_array_copy()` was doing a `memcpy()` of
the data from the old array to the new one, based on the reserved
elements in the old array (`array->alloc`). However, the new array was
allocated based on the *assigned* elements in the old array
(`array->len`).
So if the old array had fewer assigned elements than allocated elements,
`memcpy()` would fall off the end of the newly allocated data block.
This was particularly obvious when the old array had no assigned
elements, as the new array’s data pointer would be `NULL`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #2049
glibc declares memcpy() with the first two arguments (the pointers)
annotated as non-null via an attribute, which results in the undefined
behaviour sanitizer considering it to be UB to pass a null pointer
in the second argument, even if we are copying 0 bytes (and hence not
actually dereferencing the pointer).
This shows up in array-test when run with the undefined behaviour
sanitizer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Note that I deliberately haven't used g_autoptr here, because while we
encourage GLib users to use g_autoptr in their own code, GLib itself
still supports being compiled in environments like MSVC that can't
support g_autoptr.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The user_data for g_ptr_array_sort_with_data is passed directly, not
with an extra layer of pointer like the data pointers.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 52c130f8
Let's not encourage library users to sprinkle casts through their code
when they don't need to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 52c130f8
If searching for an element which is smaller than every element in the
array (i.e. the element being searched for is not in the array), the
previous g_array_binary_search() implementation would underflow in the
calculation `right = middle - 1`, and end up trying to dereference an
element way off the right of the array.
Fix that by checking the additions/subtractions before doing them, and
bailing if the bounds are hit. We don’t need to check `middle <
G_MAXUINT`, as `middle` is bounded above by `right`, which is always `<=
_array->len - 1`, and `_array->len <= G_MAXUINT`.
Add some tests for that, and for not-present elements in the middle of
the array. Previously, the tests only checked for not-present elements
which were bigger than every element in the array.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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
