We only want to include gslist.h here if it was not already included via
including glib.h, as:
* gslist.h should normally be included via glib.h if used outside of
GLib itself.
* This broke Visual Studio builds that use GResources (via
glib-compile-resources.exe) as that would cause the generated code to
include gslist.h directly, which is therefore disallowed.
This can happen if a caller (ab)uses `execve()` to execute a gtest
process with an empty `argv` array. `g_test_init()` has to gracefully
handle such a situation.
Fix a few problem areas in the code, and add a simple test which checks
that `g_test_init()` doesn’t crash when called with an empty `argv`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While `execve()` might allow (probably malicious) users to execute a
program with an empty `argv` array, gspawn does not. It’s not actually
possible, as the path to the binary to execute is not specified
separately from the argument array.
Explicitly document and encode that in preconditions.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It is not possible for `g_shell_parse_argv()` to return an empty `argv`
array. Make that clear in the documentation and add some assertions to
encode it explicitly in the code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
There shouldn’t be any issues here with empty argv arrays since an empty
`Exec=` line is already checked for. Encode that explicitly with an
assertion.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This won’t really affect anything, but we might as well fix them to not
crash if called with an empty `argv` by someone (ab)using `execve()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it’s not usual, it is possible for applications to be called with
an empty `argv` by a process (ab)using `execve()`. Modify the
`GApplication` code example to handle that possibility, so that anyone
copying the example isn’t introducing a bug into their program
immediately.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When working with storage (especially GInputStream or GOutputStream) it
is preferred to use page-aligned buffers so that the operating system
can do page-mapping tricks as the operation passes through the kernel.
Another use case is allocating memory used for vectorised operations,
which must be aligned to specific boundaries.
POSIX and Windows, as well as the C11 specification, provide this kind
of allocator functions, and GLib already makes use of it inside GSlice.
It would be convenient to have a public, portable wrapper that other
projects can use.
Fixes: #2574
This will not reproduce the bug when run as a unit test, because in that
scenario, G_TEST_BUILDDIR and G_TEST_SRCDIR are set. It *can* reproduce
the bug (at least probabilistically) when run as an installed-test,
or manually in a build tree:
./_build/glib/tests/testing
Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/2563
Signed-off-by: Simon McVittie <smcv@collabora.com>
If `GDebugControllerDBus` remains as the only, or default,
implementation of `GDebugController`, `dup_default()` cannot work.
`GDebugControllerDBus` requires a `GDBusConnection` at construction
time, which the `GIOModule` construction code can’t provide it.
Either we use a default D-Bus connection (but which one? and how would
it be changed by the user later if it was the wrong one?), or delegate
singleton handling of the `GDebugController` to the user.
The latter approach seems more flexible.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1190
The test is meant to check read-only files don't get overwritten, which
is 0400 in octal.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
