Previously, these tests would always pass. If the precondition check
failed (as we want it to), the subprocess would exit unsuccessfully;
but if the precondition check wrongly passed, the subprocess would
continue, allocate a nonzero amount of memory, and fail the
g_assert_null(), resulting in the subprocess exiting unsuccessfully
and the test still passing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On ILP32 platforms, 4 is a valid alignment for g_aligned_alloc(), so
use 2 as our invalid alignment instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
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>
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>
Much like GBindingGroup, the GSignalGroup object allows you to connect many
signal connections for an object and connect/disconnect/block/unblock them
as a group.
This is useful when using many connections on an object to ensure that they
are properly removed when changing state or disposing a third-party
object.
This has been used for years in various GNOME projects and makes sense to
have upstream instead of multiple copies.
Originally, GBindingGroup started with Builder as a way to simplify all
of the third-degree object bindings necessary around Model-Controller
objects such as TextBuffer/TextView.
Over time, it has grown to be useful in a number of scenarios outside
of Builder and has been copied into a number of projects such as GNOME
Text Editor, GtkSourceView, libdazzle, and more.
It makes sense at this point to unify on a single implementation and
include that upstream in GObject directly alongside GBinding.
On Windows, process spawning needs an external helper exe which is found
relatively to the glib DLL file. If glib has been built statically this
file doesn't exist anymore and reference path is not the DLL path
anymore but the current executable path.
This patch searches for the helper exe taking as starting point the
current executable path, relative 'bin', 'lib', 'glib' and 'gio' folders
and then gets one level up until the root path. If this search doesn't
give result then the helper exe is searched using the PATH variable.
Fix a possibility of returning a relative path, in case PATH contains
a relative path. According to the doc, the function should return an
absolute path.
Signed-off-by: Christoph Niethammer <christoph.niethammer@gmail.com>
This is an API analogue of the G_MESSAGES_DEBUG environment variable. It
is intended to be exposed outside applications (for example, as a D-Bus
interface — see follow-up commits) so that there is a uniform interface
for controlling the debug output of an application.
Helps: #1190
