This reverts commit 5190354ad95c5a10fdde037de8177797ae4a7384.
Now that g_close isn't called from gspawn anymore, we can reenable
the g_close warning on macOS.
Closes: #2785
Some platforms (e.g., macOS) don't currently have a way
to close only open fds in preparation for exec. On these
platforms, glib just bites the bullet and calls g_close for
the whole fileno range.
g_close only allows valid fds to be given to it, though.
This commit ensures close is called instead of g_close on
those platforms by splitting the safe_fdwalk implementation
that operates on invalid fds off to its own function and
only using it as a fall back.
It's possible when gspawn sets up its pipes for standard io,
that the pipe fds themselves end up in the standard io range
reserved for stdin, stdout, stderr.
This commit protects against that problem by relocating the
fds up, outside of the range.
Closes: #16
The error code is already used for both F_DUPFD and dup2
already, and having dup2 in the name is oddly specific.
This renames the error code for clarity.
Now that we know it's a bad idea to avoid the standard io fd range
when getting pipe fds for g_unix_open_pipe, we should test to make sure
we don't inadvertently try to do it again.
This commit adds that test.
g_unix_open_pipe tries to avoid the standard io fd range
when getting pipe fds. This turns out to be a bad idea because
certain buggy programs rely on it using that range.
This reverts commit d9ba6150909818beb05573f54f26232063492c5b
Closes: #2795Reopens: #16
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The platform-specific predefined macros provided by various compilers
sometimes capture subtle differences of meaning, like the distinction
between the Linux kernel and a glibc-based (GNU/Linux) user-space.
It would be difficult to capture those subtleties in GLib-specific
convenience macros, particularly for platforms that we don't use
ourselves.
Instead, recommend that anyone who is already writing platform-specific
code should use the platform-specific predefined macros directly.
Alternative to !2986.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Various glib tests (such as the spawn ones) depend on local binaries
being built, this may not happen (especially when not using installed
tests), thus ensure such dependencies via the newly added extra_programs
key
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
We have tests that are failing in some environments, but it's
difficult to handle them because:
- for some environments we just allow all the tests to fail: DANGEROUS
- when we don't allow failures we have flacky tests: A CI pain
So, to avoid this and ensure that:
- New failing tests are tracked in all platforms
- gitlab integration on tests reports is working
- coverage is reported also for failing tests
Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).
Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
- Non-flaky tests cannot fail in all platforms
- Failing and Flaky tests can fail
In both cases we save the test reports so that gitlab integration is
preserved.
We have gnulib warnings in windows under clang:
../glib/gnulib/vasnprintf.c:2429:21: warning: variable 'flags' set but not
used [-Wunused-but-set-variable]
int flags = dp->flags;
^
../glib/gnulib/vasnprintf.c:4853:19: warning: unannotated fall-through
between switch labels [-Wimplicit-fallthrough]
case TYPE_LONGINT:
^
See: https://gitlab.gnome.org/3v1n0/glib/-/jobs/2361750
C99 does not actually guarantee that the platform has 8-, 16-, 32- and
64-bit types, but it does guarantee that if the platform has them, then
(u)intN_t are defined to be examples of those types.
GLib goes beyond what C99 guarantees, and requires 8-, 16-, 32- and
64-bit types; combining that with C99's requirements means we can
assume that int8_t, uint64_t, etc. all exist.
Unfortunately, we cannot guarantee that GLib and the C99 toolchain have
chosen the *same* fixed-size type: for example, on a typical ILP32
or LLP64 platform like Windows or 32-bit Linux, each 32-bit type could
either be int or long, while on a LP64 platform like 64-bit Linux,
each 64-bit type could either be long or long long. The in-memory
representation is the same either way, but the choice of underlying type
matters when building printf format strings or issuing compiler warnings.
As a result, we can't just typedef gint32 as int32_t and so on.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
The important thing here is that we can't arbitrarily mix these, even if
they will often have the same in-memory representation.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
These have a status similar to size_t: they're Standard C types and
straightforward to use in portable code this decade, but we can't
guarantee that we have chosen the same underlying type that the platform
uses.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is similar to the relationship between gsize and size_t, except
that size_t is a Standard C type but ssize_t is platform-specific
(specifically, ssize_t is a POSIX type, and on Windows the equivalent
is SSIZE_T), making it more awkward to use in portable code. As a
result, continuing to use gssize is more useful than continuing to use
gsize.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have chosen the underlying type that implements gsize to be the same
size as the standard C89 size_t (the top-level meson.build sets this up).
Unfortunately, we cannot guarantee that GLib and the C toolchain have
chosen the *same* fixed-size type: for example, on a typical ILP32
platform like 32-bit Windows or Linux, each of gsize and size_t
can either be int or long, while on a LP64 platform like 64-bit Linux,
each could either be long or long long. meson.build tries to choose the
same type to reduce compiler warnings, but it can only do this if the
compiler implements `-Werror`.
The in-memory representation is the same either way, but the choice of
underlying type matters when building printf format strings or issuing
compiler warnings, and can affect the C++ ABI of GLib-based software.
As a result, we can't just typedef gsize as size_t.
I've expanded the doc-comment to say a bit more about the implications
of the different types here, so that I can point to it from the
doc-comments of other types without repeating myself too much.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
G_MODULE_SUFFIX is deprecated now because you will get the wrong
results using it most of the time:
1. The suffix on macOS is usually 'dylib', but it's 'so' when using
Autotools, so there's no way to get the suffix correct using
a pre-processor macro.
2. Prefixes also vary in a platform-specific way. You may or may not have
a 'lib' prefix for the name on Windows and on Cygwin the prefix is
'cyg'.
3. The library name itself can vary per platform. For instance, you may
want to load foo-1.dll on Windows and libfoo.1.dylib on macOS. This
is for libraries, not modules, but that is still a use-case that
people use the GModule API for.
g_module_build_path() does take care of (2) on Cygwin, but it
fundamentally cannot handle the possibility of multiple options for
the module name, since it does not do any I/O. Hence, it is also
deprecated.
Instead, g_module_open() has been improved so that it takes care of
all this by searching the filesystem for combinations of possible
suffixes and prefixes on each platform. Along the way, the
documentation for it was also improved to make it clearer what it
does.
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/520
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/1413
In principle we could script this so that each max-version.c is compiled
26 times, once per possible MAX_VERSION, but I haven't implemented
that here: just pinning to the oldest possible version is sufficient to
reproduce #2796.
These aren't included in the installed-tests, since they don't really
do anything at runtime (the important thing is that they compile
without warnings).
Reproduces: #2796
Signed-off-by: Simon McVittie <smcv@collabora.com>
Whenever a static inline calls a GLib function that was added since
we started tracking versions, we need to silence the "Not available
before" warnings, otherwise compiling code that includes this header
with GLIB_VERSION_MAX_ALLOWED set to an old version will emit warnings,
even if the static inline is never actually called.
If the static inline is API, we also need to ensure it is annotated with
GLIB_AVAILABLE_STATIC_INLINE_IN_2_76 or similar, so that callers get
the appropriate "Not available before" warnings to alert them to their
unintended use of newer API.
g_clear_fd() calls a function that was introduced in 2.36. It already
issues its own warning if called with GLIB_VERSION_MAX_ALLOWED less
than 2.76.
Similarly, g_autofd uses internal function _g_clear_fd_ignore_error
which calls g_clear_fd(), but it issues its own warning if used with
GLIB_VERSION_MAX_ALLOWED less than 2.76.
Fixes: b3934133 "gstdio: Add g_clear_fd() and g_autofd"
Resolves: #2796
Signed-off-by: Simon McVittie <smcv@collabora.com>
Inspired by libglnx's glnx_close_fd() and glnx_autofd, these let us
have the same patterns as g_clear_object() and g_autoptr(GObject), but
for file descriptors. g_clear_fd() is cross-platform, while g_autofd
is syntactic sugar requiring a supported compiler (gcc or clang).
Now that g_close() checks for EBADF as a programming error, we can
implement the equivalent of glnx_autofd as an inline function without
needing to have errno and EBADF in the header file.
g_clear_fd() is like glnx_close_fd(), but with error checking.
The private _g_clear_fd_ignore_error() function used to implement
g_autofd is a closer equivalent of glnx_close_fd().
Signed-off-by: Simon McVittie <smcv@collabora.com>
C99 guarantees that va_copy() exists, so use it, instead of probing
for __va_copy(), va_copy(), or a reimplementation from first principles.
Signed-off-by: Simon McVittie <smcv@collabora.com>
