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>
The behaviour of `g_variant_byteswap()` is largely dominated by its call
to `g_variant_get_normal_form()`, but it does do an additional call to
`g_variant_serialised_byteswap()` which we should probably be fuzzing.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We were regressing on Python style too often. Since Python code style is
a lot easier to enforce than C code style, split it (and the shellcheck
checks) out from `style-check-diff` into a new CI job which is allowed
to fail the pipeline.
Only trigger it when .sh or .py files have changed, which should reduce
resource consumption.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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>
There is usually no reason to use the GLib-specific type names here,
other than consistency. The GLib-specific one-word type names can
sometimes be a little more convenient when generating a family of
function names from macros.
Because these types are simple aliases for a hard-coded standard C type,
there should be no API or ABI issues caused by changing existing code to
use the standard C names: a `char **` can already be used interchangeably
with `gchar **`, and name-mangling for a C++ method that takes an `int`
parameter is equivalent to a `gint` parameter.
Helps: #1484
Signed-off-by: Simon McVittie <smcv@collabora.com>
Introduce support for terminals executing commands without an option,
i.e., the command is passed directly as argument to the terminal emulator.
This is needed for xdg-terminal-exec.
Get rid of multiple conditionals branch by using a loop and storing the
options needed by particular terminal emulators directly in an array.
Remove intermediate variable term_argv as we don't need it.
Advantages:
- simpler logic, less branching
- the terminal emulator list is more readable, by virtue of being
condensed in one array. Launch options to execute a terminal program
are also more explicitly specified
- the logic become independent from the order
- one less allocation
The gversionmacros.h header is referenced from glib/, so it needs to go
into glib's include directory, not in the top-level alongside glib.h,
glib-object.h, gmodule.h, and glib-unix.h.
