None of these messages are particularly helpful, but they increase the
overall test log output size, which has to be stored by the CI for every
test run.
With these messages removed, the size of a full test log is reduced from
6.5MB to 1.8MB for me.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
GArray supports a "zero_terminated" flag, but GPtrArray doesn't.
This is odd, because especially for a pointer array it makes sense
to have a %NULL sentinel. This would be for example useful to track
or construct a strv array with a GPtrArray.
As workaround for this missing feature you could use a GArray instead
(ugly) or to explicitly add the %NULL element. However the latter increases
the "len" of the array, which can be problematic if you want to still use
the GPtrArray for other purposes.
Add API for marking a GPtrArray as %NULL terminated. In that case, the
API will ensure that there is always a valid %NULL sentinel after the
array. Note that the API does not enforce that a %NULL terminated API
actually has any data allocated. That means, even with a %NULL terminated
array, pdata can still be %NULL (only if len is zero).
Add g_ptr_array_new_null_terminated() constructor. The null-terminated flag
cannot be cleared. Once the GPtrArray is flagged to be %NULL terminated, it
sticks. The purpose is that once a user checks whether a GPtrArray instance
is safe to be treated as a %NULL terminated array, the decision does
not need to be re-evaluated.
Also add a g_ptr_array_is_null_terminated(). That is useful because it
allows you to check whether a GPtrArray created by somebody else is safe
to use as a %NULL terminated array. Since there is no API to make an
array not %NULL terminated anymore, this is not error prone.
The new flag is tracked as a guint8 in GRealPtrArray. On common 64 bit
architectures this does not increase the size of the struct as it fits
in an existing hole. Note that this is not a bitfield because it's
probably more efficient to access the entire guint8. However, there is
still a 3 bytes hole (on common 32 and 64 architectures), so if we need
to add more flags in the future, we still have space for 24 bits,
despite the new flag not being a bitfield.
The biggest downside of the patch is the runtime overhead that most
operations now need to check whether %NULL termination is requested.
Includes some tweaks and additional tests by Philip Withnall.
https://gitlab.gnome.org/GNOME/glib/-/issues/353
Instead store a bit inside `GTimeoutSource` and `GIdleSource` to
indicate that they are one-shot sources, and that their callbacks have a
different type and should always be assumed to return `G_SOURCE_REMOVE`.
This should make one-shot idle and timeout sources a teeny weeny little
bit cheaper to set up.
From a suggestion here: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2684#note_1462917
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This allows it to be reused and extended (internally) a little more.
This commit introduces no functional changes, but allows for more easy
additions in a following commit.
It introduces `GIdleSource` as a simple wrapper around `GSource`, which
will be extended in a following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This allows it to be reused and extended (internally) a little more.
This commit introduces no functional changes, but allows for more easy
additions in a following commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Many idle and timeout sources are installed as "one shot": called once
and immediately removed. While it's easy to write a simple callback that
returns G_SOURCE_REMOVE, it would also be useful to have some sort of
"visual" marker when reading the code; a way to immediately see that a
callback (which may be defined elsewhere in the code) is meant to be
invoked just once.
Includes additional unit tests by Philip Withnall.
Sysprof recently cleaned up it's build configuration options. This is
perhaps a good time to update GLib to point at an updated commit'ish and
use the new options.
If now is not a good time to do the update, that is completely fine, but
I wanted to give you a turn-key MR nonetheless.
This is more efficient than calling
g_datalist_id_remove() multiple times
in a row, since it only takes the locks
once.
Allow up to 16 keys to be removed in one go.
That is enough for the use we have in GObject,
and it avoids any danger of blowing the stack.
The user data parameters in callbacks need to be named user_data to
generate correct closure attributes in the introspection data. This
updates parameters missed in GNOME/glib!2633.
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files glib/tests/*.c | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files glib/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
==24477==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffde020de20 at pc 0x7f2e6f6413f1 bp 0x7ffde020c9d0 sp 0x7ffde020c180
READ of size 4101 at 0x7ffde020de20 thread T0
#0 0x7f2e6f6413f0 in __interceptor_strlen.part.0 (/lib64/libasan.so.8+0x4c3f0)
#1 0x7f2e6ef4abee in g_build_path_va ../glib/gfileutils.c:1908
#2 0x7f2e6f085956 in g_test_build_filename_va ../glib/gtestutils.c:4294
#3 0x7f2e6f086684 in g_test_build_filename ../glib/gtestutils.c:4365
#4 0x403a33 in test_search_path_heap_allocation ../glib/tests/spawn-path-search.c:422
#5 0x7f2e6f0839a5 in test_case_run ../glib/gtestutils.c:2930
#6 0x7f2e6f0839a5 in g_test_run_suite_internal ../glib/gtestutils.c:3018
#7 0x7f2e6f0834ed in g_test_run_suite_internal ../glib/gtestutils.c:3035
#8 0x7f2e6f084879 in g_test_run_suite ../glib/gtestutils.c:3112
#9 0x7f2e6f084995 in g_test_run ../glib/gtestutils.c:2231
#10 0x40145f in main ../glib/tests/spawn-path-search.c:488
#11 0x7f2e6e31258f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
#12 0x7f2e6e312648 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x2d648)
#13 0x401524 in _start (/home/elmarco/src/gnome/glib/build/glib/tests/spawn-path-search+0x401524)
Address 0x7ffde020de20 is located in stack of thread T0 at offset 4256 in frame
#0 0x40387f in test_search_path_heap_allocation ../glib/tests/spawn-path-search.c:401
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This bug only gets triggered on BSD, because it calls `recv_message()`
with `G_IO_HUP | G_IO_IN`. That takes two code paths in
`recv_message()`, and ends up calling `shutdown_source()` twice. The
second call causes a critical warning.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/jobs/2004192
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The g_spawn_async_with_pipes_and_fds() API changes its behavior
depending on the states of out parameters. Apart from the philosophical
inconsistency, this poses some real problems, e.g. in Lua bindings:
https://github.com/lgi-devs/lgi/issues/277
This adds three new spawn flags to allow specifying the wanted behavior
explicitly and does not assert on the state of the output parameters.
Check the spawn implementation behaviour when the stderr is a
socket (mostly for win32).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Used in following commits, including in some GIO experiments, so make it
a private API.
For now, this implementation is similar to the glib/gspawn-win32.c one,
with mroe error checking and better on error behaviour. A following
patch will also fix the case of duplicating sockets.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This will help static analysers, similarly to with the previous commit.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
