"lower bound" and "upper bound" operations have been recently added to
GTree.
Let's add some tests for them where other GTree tests live.
Since adding keys in-order doesn't exercise the GTree insertion code very
well let's make sure they are inserted in a random order instead.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
The basic API that this commit adds allows in-order iterating over a GTree.
For this the following API were implemented or exported:
1) Returning the first or the last node in the tree,
2) Taking a pointer to a node in the tree and returning the previous or the
next in-order node,
3) Allowing to do a binary search for a particular key value and returning
the pointer to its node,
4) Returning the newly inserted or set node from both insert and replace
functions, so this node is immediately available and does not have to be
looked up,
5) Traversing the tree in-order providing a node pointer to the
caller-provided traversal function.
Most of the above functions were already present in the code, but they
returned the value that is stored at a particular node instead of the
pointer to the node itself.
So most of the code for these new API calls is shared with these existing
ones, just adapted to return the pointer to the node.
Additionally, the so called "lower bound" and "upper bound" operations
were implemented.
The first one returns the first element that is greater than or equal to
the searched key, while the second returns the first element that is
strictly greater than the searched key.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
* Add a debug assert checking whether we have really removed all nodes in
g_tree_remove_all(),
* Print a "LEFT" and "RIGHT" headers before printing a particular tree
branch in g_tree_node_dump(),
* Make the whole thing actually buildable again in the debug mode by
conditionally providing g_tree_dump() declaration in glib/gtree.h.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
The return value from `g_utf8_get_char_validated()` is a `gunichar`,
which is unsigned, so comparing it with `> 0` is always going to return
true, even for return values `(gunichar) -1` and `(gunichar) -2`, which
indicate errors.
Handle them more explicitly.
oss-fuzz#26083
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If this fails to compile on some particularly bizarre Unix platform,
we can relax these assertions; but our expectation is that gssize is
POSIX ssize_t, and that on Unix, GPid is POSIX pid_t.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a step towards glib#1484. We officially require a C99 toolchain,
so we can statically assert that our artisanal hand-crafted integer
types are compatible with the ones we would like to recommend people
use instead.
If there are *still* platforms where <stdint.h> is problematic, these
static assertions can act as an early-warning that future GLib releases
will make a C99-compliant <stdint.h> a hard requirement, in ways that
are less straightforward to avoid (see glib#1484 and glib!1300).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This combines a massive code re-folding with functionlity expansion
that allows us to track multiple verbs per handler or per application.
Also fixes a few issues and removes a function that made no sense.
Like G_SOURCE_REMOVE and G_SOURCE_CONTINUE, these make it clearer what
it means to return TRUE or FALSE.
In particular, in GDBus methods that fail, the failure case still needs
to return TRUE (unlike the typical GError pattern), leading to comments
like this:
g_dbus_method_invocation_return_error (invocation, ...);
return TRUE; /* handled */
which can now be replaced by:
g_dbus_method_invocation_return_error (invocation, ...);
return G_DUS_METHOD_INVOCATION_HANDLED;
G_DBUS_METHOD_INVOCATION_UNHANDLED is added for symmetry, but is very
rarely (perhaps never?) useful in practice.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It was disabled in !875 because lcov didn't support the new coverage
format produced by gcc9+. The latest lcov release in MSYS2 supports
it again, so re-enable everything.
lcov now writes native Windows paths to its output so adjust the path
fixup script to handle those.
This is exactly the test case from oss-fuzz which triggers a negative
overflow when constructing dates.
oss-fuzz#22758
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This bumps the coverage of `parse_host()` and `parse_ip_literal()` up to
100% of lines and branches.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The previous parsing code could read off the end of a URI if it had an
incorrect %-escaped character in.
Fix that, and more closely implement parsing for the syntax defined in
RFC 6874, which is the amendment to RFC 3986 which specifies zone ID
syntax.
This requires reworking some network-address tests, which were
previously treating zone IDs incorrectly.
oss-fuzz#23816
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Having the goto labels at the bottom of a function makes things a little
more readable. This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This introduces no functional changes, but makes the memory ownership a
little clearer and reduces the length of the code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This introduces no functional changes, but will make future changes to
the code a little cleaner.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If the old value is destroyed before updating the TLS value in pthreads
(or the Windows equivalent) then there’s a risk of infinite recursion if
`g_private_replace()` is called from within the `GDestroyNotify`.
Avoid that by destroying the old value after doing the TLS update.
Thanks to Matthias Clasen for diagnosing the issue.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2210
g_module_symbol() internally calls CreateToolhelp32Snapshot() which
in some circumstances returns ERROR_BAD_LENGTH and according to the docs
should lead to CreateToolhelp32Snapshot() being retried by the caller.
This retry logic was missing and for example led to g_module_symbol()
not succeeding if another thread happened to call the wrong function
at the wrong time.
This got noticed in the g-i build of gtk4 where g-i would call g_module_symbol()
on all gtk4 _get_type symbols and while inspecting the properties gtk4 would
spawn a thread calling SHGetSpecialFolderLocation() somewhere down the line.
During the call to SHGetSpecialFolderLocation() CreateToolhelp32Snapshot() would
return with ERROR_BAD_LENGTH for a short period of time and make g_module_symbol()
fail, which lead to "Invalid GType function" errors in g-i.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3213
Emptying trash over `gio trash` is a bit slow in comparison to plain
`rm -r`. On my system, it took about 3 min to empty the trash with a
folder containing 600 000 files, which is not ideal as `rm -r` call
took just a few seconds. I found that `g_file_delete` is implemented
differently for locations provided by the trash backend. The trash
backend prevents modifications of trashed content thus the delete
operation is allowed only for the top-level files and folders. So it
is not necessary to recursive delete all files as the permission
denied error is returned anyway. Let's call `g_file_delete` only for
top-level items, which reduces the time necessary for emptying trash
from minutes to seconds...
See: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1589
