This class provides the shared functions, such as sending a signal and
string and value conversion. The backend classes should inherit this
class to get the shared functions.
It adds a configure time check for `sysinfo()`, as some systems don’t
have it.
Apply GArray's g_array_maybe_expand overflow checking logic to
GPtrArray's g_ptr_array_maybe_expand function:
Let g_ptr_array_maybe_expand handle the null_terminated flag internally
to check if an overflow occurs instead of letting callers do these
check on their own.
The g_ptr_array_copy function lacked this check.
Having a centralized position for this check simplifies the code and
further code auditings.
The functions g_array_new_take_zero_terminated and
g_ptr_array_new_take_null_terminated must take into account that the
last element will be the terminating element (zero filled or NULL).
Iterating through all elements must not reach G_MAXUINT, because in
that case no space is left for the terminating element.
Call these vfuncs also for cases where the launching instance
is the primary one. This is what the docs suggest, and it makes
before/after_emit much more useful.
Fixes: #3726
Existing uses of before_emit in GTK will break if an app overrides
before/after_emit without chaining up. Clarify in the documentation
that these vfuncs need to chain up.
The dbus-appinfo test was asserting that before_emit only happens
when we haven't seen a startup ID yet. But the docs imply that it
gets emitted for every activate/open/commandline, which may well
happen repeatedly. So drop this assertion.
The g_array_new_take_zero_terminated function could lead to NULL
data pointer if it is called with (NULL, FALSE, x), i.e. with a NULL
pointer and no clear request.
This in turn means that g_array_steal could behave like
g_ptr_array_steal, i.e. it would return NULL instead of a zero
terminated array, which does not match its description.
Also, g_array_remove_range and g_array_set_size could lead to NULL
pointer dereferences with such arrays.
Support all these cases and adjust the API description to reflect
current behavior. It brings GArray and GPtrArray functionality closer
to each other without breaking existing API/ABI for programs.
The g_string_append_vprintf function could overflow with strings
which are INT_MAX bytes long. The eventual memcpy call copies INT_MAX
plus additional nul byte into newly allocated memory. This means
that due to signed integer overflow more bytes are copied than
could ever fit.
The multiplication of two guint values could overflow with large
arrays. Use g_array_elt_len and g_array_elt_pos to avoid explicit
elt_size multiplications.
Tests currently fail under macOS because the tool claims not to work
on apple devices. Since I cannot disprove this myself, I'm disabling the
tests on Darwin.
As per the desktop entry specification, the `%k` field code should be
expanded to the location of the desktop entry file being processed. This
is only possible if the constructor-only filename property is populated,
which does not happen when using g_desktop_app_info_new_from_keyfile().
Moreover, since the Path directive in a desktop entry can be used to
set the working directory for the program to be launched, the location
passed as argument to the program must be modified such that it points
at the correct file when interpreted by the launched program. The
simplest way to achieve this consistently is to pass an absolute path.
However, g_desktop_app_info_new_from_keyfile() does not indicate why it
fails when it does. Because the tool aims to indicate whether launching
failed due to a missing file or a malformed one we first check this with
g_key_file_load_from_file().
This introduces an integration test that executes gio launch from a
variety of working directories, and checks that %k is expanded to a
location that makes sense in the context of the executed program, i.e.
an absolute path.
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>
Each enumerated address can be of a different family type, so you have to make a socket after you have that information.
As this is just a test client we make a new socket each time for simplicity.
