If a source is using g_source_set_callback_indirect(), then performing
GSource operations within GSourceCallbackFuncs::unref should not cause a
deadlock.
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/3725
Use the same style for the G_LIKELY check here as in g_string_sized_new.
The check could overflow on 32 bit systems.
Also improve the memcpy/memmove check to use memcpy if val itself is
adjacent to end + len_unsigned, which means that no overlapping exists.
If glib is compiled with -Dglib_assert=false, i.e. no asserts
enabled, then g_string_sized_new(G_MAXSIZE) leads to a segmentation
fault due to an out of boundary write.
This happens because the overflow check was moved into
g_string_maybe_expand which is not called by g_string_sized_new.
By assuming that string->allocated_len is always larger than
string->len (and the code would be in huge trouble if that is not true),
the G_UNLIKELY check in g_string_maybe_expand can be rephrased to
avoid a potential G_MAXSIZE overflow.
This in turn leads to 150-200 bytes smaller compiled library
depending on gcc and clang versions, and one less check for the most
common code paths.
Reverts https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4655 and
reorders internal g_string_maybe_expand check to still fix
CVE-2025-6052.
The WIF* macros are supposed to be used with the status, not the pid.
Also, only check the status if no error occurred, otherwise the value
might be uninitialized. If an unrecoverable error occurs, break the
loop (could happen if SIGCHLD is ignored).
`g_file_enumerator_finalize` should not call `g_file_enumerator_close`
because object parts (i.e. subclass variable and/or resources) might
already be freed, causing memory safety issues.
A better place to call `g_file_enumerator_close` is
`g_file_enumerator_dispose` because it is safe to access the object
memory here.
Fixes#3713
Signed-off-by: fbrouille <150549-fbrouille@users.noreply.gitlab.gnome.org>
g-ir-scanner won't pick Since or Deprecated annotations if they are
inlined, they need a dedicated documentation block for this to work. The
since annotation is used, e.g. in gtk-rs, to not expose enum flags if
not compiled declaring we have a new enough glib version.
Verify that you can delete the file from the trash before moving it, if
the file is a directory owned by the user, recursively check for
non-empty directory not owned by he user.
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/1665
There is a bunch of documentation in a separate markdown page that does
not appear in search results. We should point to it.
I think the restriction on not being used to process untrusted input
should be relaxed into something more permissive, like "should not be
used on untrusted input if you care about denial of service." But that
can be a problem for another day.
There are four `Unix.+` classes in `Gio-2.0.gir` which need to be
exposed in the `Gio-2.0.gir` docs because they are actually now
cross-platform (which is a move which has caused a lot of pain).
Change the code which filters out the rest of the `Unix.+` classes to
ignore these ones. The rest of the classes continue to be documented via
`GioUnix-2.0.gir`.
Changing the regexs for this involved a fun use of negative lookahead.
See https://gitlab.gnome.org/GNOME/glib/-/issues/3697#note_2459405
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3697
After commit 34b7992fd6 the overflow check
was only done when expanding the string, but we need to do it before
checking whether to expand the string, otherwise that calculation could
overflow and falsely decide that the string is big enough already.
As a concrete example, consider a `GString` which has:
* `.len = G_MAXSIZE / 2 + 1`
* `.allocated_len = G_MAXSIZE / 2 + 1`
and `g_string_append()` is called on it with an input string of length
`G_MAXSIZE / 2`.
This results in a call `g_string_maybe_expand (string, G_MAXSIZE / 2)`,
which calculates `string->len + len` as `(G_MAXSIZE / 2 + 1) +
(G_MAXSIZE / 2)` which evaluates to `1` as it overflows. This is not
greater than `string->allocated_len` (which is `G_MAXSIZE / 2 + 1`), so
`g_string_expand()` is *not* called, and `g_string_maybe_expand()`
returns successfully. The caller then assumes that there’s enough space
in the buffer, and happily continues to cause a buffer overflow.
It’s unlikely anyone could hit this in practice because it requires
ludicrously big strings and `GString` allocations, which likely would
have been blocked by other code, but if we’re going to have the overflow
checks in `GString` then they should be effective.
Spotted by code inspection.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
