GLib merge requestshttps://gitlab.gnome.org/GNOME/glib/-/merge_requests2019-07-12T10:16:57Zhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/955gmacros: Use _Static_assert when C11 is available2019-07-12T10:16:57ZNirbheek Chauhangmacros: Use _Static_assert when C11 is availableThe static assert message is much nicer to read, and is less likely to be misinterpreted as a false positive.
glib is built with `-std=gnu89`, but this macro will be available to projects that use glib with c11 or gnu11. I built glib ...The static assert message is much nicer to read, and is less likely to be misinterpreted as a false positive.
glib is built with `-std=gnu89`, but this macro will be available to projects that use glib with c11 or gnu11. I built glib with `-Dc_std=gnu11` to verify that it works fine with glib's code. I have also built all of gstreamer to confirm that nothing breaks in there.
Before:
```
In file included from glib/glibconfig.h:9,
from ../glib/gtypes.h:32,
from ../glib/gatomic.h:27,
from ../glib/gatomic.c:22:
../glib/gmacros.h:743:53: error: size of array ‘_GStaticAssertCompileTimeAssertion_1’ is negative
743 | #define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/gmacros.h:735:47: note: in definition of macro ‘G_PASTE_ARGS’
735 | #define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
| ^~~~~~~~~~~
../glib/gmacros.h:743:44: note: in expansion of macro ‘G_PASTE’
743 | #define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
| ^~~~~~~
../glib/gatomic.c:102:1: note: in expansion of macro ‘G_STATIC_ASSERT’
102 | G_STATIC_ASSERT (sizeof (gint) == 8);
| ^~~~~~~~~~~~~~~
```
After:
```
In file included from glib/glibconfig.h:9,
from ../glib/gtypes.h:32,
from ../glib/gatomic.h:27,
from ../glib/gatomic.c:22:
../glib/gmacros.h:739:31: error: static assertion failed: "Expression evaluates to false"
739 | #define G_STATIC_ASSERT(expr) _Static_assert (expr, "Expression evaluates to false")
| ^~~~~~~~~~~~~~
../glib/gatomic.c:102:1: note: in expansion of macro ‘G_STATIC_ASSERT’
102 | G_STATIC_ASSERT (sizeof (gint) == 8);
| ^~~~~~~~~~~~~~~
```https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1028gmessages: Add g_warning_once()2019-10-09T15:10:08ZJonas Ådahlgmessages: Add g_warning_once()In many places the pattern
static gboolean warned_once = FALSE;
if (!warned_once)
{
g_warning ("This and that");
warned_once = TRUE;
}
is used to not spam the same warning message over and o...In many places the pattern
static gboolean warned_once = FALSE;
if (!warned_once)
{
g_warning ("This and that");
warned_once = TRUE;
}
is used to not spam the same warning message over and over again. Add a
helper in glib for this, allowing the above statement to be changed to
g_warning_once ("This and that");
- [x] Tag with `GLIB_AVAILABLE_IN_2_64` once available2.63.1https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1210gdbus-server-auth test: Include gcredentialsprivate.h2019-11-04T16:13:56ZSimon McVittiegdbus-server-auth test: Include gcredentialsprivate.hOtherwise we'll never test the EXTERNAL-only mode, because that relies
on testing the private macros
G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED and
G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED.
This results in the 'out' lab...Otherwise we'll never test the EXTERNAL-only mode, because that relies
on testing the private macros
G_CREDENTIALS_UNIX_CREDENTIALS_MESSAGE_SUPPORTED and
G_CREDENTIALS_SOCKET_GET_CREDENTIALS_SUPPORTED.
This results in the 'out' label becoming unused on platforms like Linux
where EXTERNAL authentication is supported, so #ifdef it appropriately.
Fixes: 9f962ebe "Add a test for GDBusServer authentication"Simon McVittieSimon McVittiehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/1213gsocket: Improve diagnostics on bind() failure2019-11-04T16:59:34ZSimon McVittiegsocket: Improve diagnostics on bind() failureThis is in an attempt to diagnose GNOME/glib#1912.This is in an attempt to diagnose GNOME/glib#1912.Simon McVittieSimon McVittiehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/1249gio-tool-mount: Allow mounting by the given UUID2019-11-27T12:51:20ZOndrej Holygio-tool-mount: Allow mounting by the given UUID"gio mount" only allows mounting volumes using device files, but not using
UUIDs. Volume monitors for various GVfs locations usually supports just UUIDs.
It would be handy to support them also for testing purposes (because
"g_file_mount_..."gio mount" only allows mounting volumes using device files, but not using
UUIDs. Volume monitors for various GVfs locations usually supports just UUIDs.
It would be handy to support them also for testing purposes (because
"g_file_mount_enclosing_volume()" does something else than "g_volume_mount()"
in case of shares provided by GOA volume monitor for example). Let's update
"-d" option to support also UUIDs.
https://gitlab.gnome.org/GNOME/gvfs/issues/251https://gitlab.gnome.org/GNOME/glib/-/merge_requests/900Symlink-related fixes for `g_file_move()`2020-01-31T12:56:38ZOndrej HolySymlink-related fixes for `g_file_move()`The `G_FILE_COPY_NOFOLLOW_SYMLINKS` flag doesn't make sense for `g_file_move()` and thus it should be removed from documentation and should be always used in case of copy and delete fallback. This MR also brings missing options for gio t...The `G_FILE_COPY_NOFOLLOW_SYMLINKS` flag doesn't make sense for `g_file_move()` and thus it should be removed from documentation and should be always used in case of copy and delete fallback. This MR also brings missing options for gio tool manpage.
See the commit descriptions and #986.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1345gio-tool-info: Print unix mount information where available2020-02-03T13:15:00ZOndrej Holygio-tool-info: Print unix mount information where available"gio info" output doesn't contain any information about unix mounts, which
is a pity, because such info can be used for debugging purposes as various
functionality depends on g_unix_mount_at() resp. g_unix_mount_for(). Let's
print unix m..."gio info" output doesn't contain any information about unix mounts, which
is a pity, because such info can be used for debugging purposes as various
functionality depends on g_unix_mount_at() resp. g_unix_mount_for(). Let's
print unix mount info and local path if available.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Updated by Ondrej Holy <oholy@redhat.com> to resolve various issues from
https://gitlab.gnome.org/GNOME/glib/merge_requests/576.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1603GDBus: Add G_DBUS_METHOD_INVOCATION_HANDLED, _UNHANDLED2020-10-01T15:50:17ZSimon McVittieGDBus: Add G_DBUS_METHOD_INVOCATION_HANDLED, _UNHANDLED* GDBus tests: Use G_SOURCE_REMOVE, G_SOURCE_CONTINUE
The meaning of the boolean result of a GSource function is clearer if
we use these aliases.
* GDBus: Add G_DBUS_METHOD_INVOCATION_HANDLED, _UNHANDLED
Like G_SOU...* GDBus tests: Use G_SOURCE_REMOVE, G_SOURCE_CONTINUE
The meaning of the boolean result of a GSource function is clearer if
we use these aliases.
* GDBus: Add G_DBUS_METHOD_INVOCATION_HANDLED, _UNHANDLED
Like G_SOURCE_REMOVE and G_SOURCE_CONTINUE, these make it clearer what
it means to return TRUE or FALSE.
In particular, in GDBus methods that fail, the failure case still needs
to return TRUE (unlike the typical GError pattern), leading to comments
like this:
g_dbus_method_invocation_return_error (invocation, ...);
return TRUE; /* handled */
which can now be replaced by:
g_dbus_method_invocation_return_error (invocation, ...);
return G_DUS_METHOD_INVOCATION_HANDLED;
G_DBUS_METHOD_INVOCATION_UNHANDLED is added for symmetry, but is very
rarely (perhaps never?) useful in practice.
* GDBus: Use G_DBUS_METHOD_INVOCATION_HANDLED in method implementations2.67.0https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1731Make more use of g_assert_no_errno()2020-11-02T11:16:26ZSimon McVittieMake more use of g_assert_no_errno()* glib/tests/fileutils: Make more use of g_assert_no_errno()
This commit is shared with !1724.
* gio/tests/live-g-file: Use g_assert_no_errno()
* gio/tests/appmonitor: Use g_assert_no_errno()
* gio/tests/gsettings: Use g_assert_no_...* glib/tests/fileutils: Make more use of g_assert_no_errno()
This commit is shared with !1724.
* gio/tests/live-g-file: Use g_assert_no_errno()
* gio/tests/appmonitor: Use g_assert_no_errno()
* gio/tests/gsettings: Use g_assert_no_errno()
* gio/tests/gsettings: Assert that g_chmod succeeds
* gio/tests/gsettings: Assert that temporary directory ends up empty
If there are stray files left over, g_rmdir() will fail with ENOTEMPTY.
---
Spun out from !1724 because I realised there were more places where we could have used `g_assert_no_errno()` (!1204) than I had previously thought. The first commit is also in !1724.
The last two commits add new assertions. The others are just a better way to spell what we were already doing.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1898gtestutils: Add g_test_get_path() API2021-01-26T11:05:33ZJonas Ådahlgtestutils: Add g_test_get_path() APII found myself wanting to know the test that is currently being run,
where e.g. __func__ would be inconvenient to use, because e.g. the place
the string was needed was not in the test case function. Using __func__
also relies on the test...I found myself wanting to know the test that is currently being run,
where e.g. __func__ would be inconvenient to use, because e.g. the place
the string was needed was not in the test case function. Using __func__
also relies on the test function itself containing the whole path, while
loosing the "/" information that is part of the test path.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1905Start to ignore known leaks under AddressSanitizer2021-02-01T11:32:57ZSimon McVittieStart to ignore known leaks under AddressSanitizerNow based on !1908.
* error test: Don't test programmer error if asked not to
* gio: Don't run gsocketclient-slow test under sanitizers
AddressSanitizer, UndefinedBehaviourSanitizer and probably others
involve adding instr...Now based on !1908.
* error test: Don't test programmer error if asked not to
* gio: Don't run gsocketclient-slow test under sanitizers
AddressSanitizer, UndefinedBehaviourSanitizer and probably others
involve adding instrumentation into the code under test, which doesn't
go well with LD_PRELOAD modules that absolutely need to be
self-contained.
* glib-private: Add infrastructure to detect AddressSanitizer
* gtestutils: Default to -m no-undefined under AddressSanitizer
AddressSanitizer detects memory leaks, NULL parameters where only a
non-NULL parameter is expected, and other suspicious behaviour, so if
we try to test that sort of thing we can expect it to fail.
* glib-private: Add wrappers for telling AddressSanitizer to ignore leaks
* gutils: Tell AddressSanitizer not to track previous XDG directories
We reset these in some unit tests, and must deliberately leak them to
avoid having to break API.
* tests: Mark tests with AddressSanitizer-detected leaks
Various tests have leaks where it isn't clear whether the data is
intentionally not freed, or leaked due to a bug. If we mark these
tests as TODO, we can skip them under AddressSanitizer and get the
rest to pass, giving us a baseline from which to avoid regressions.
---
I haven't opened separate bugs for all the leaky tests yet, so for now they all point to this MR.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1967Distinguish more clearly between wait status and exit status2021-06-15T18:22:04ZSimon McVittieDistinguish more clearly between wait status and exit status* subprocess test: Check wait status correctly
Confusingly, g_spawn_check_exit_status() takes a wait status, not an
exit status, so passing g_subprocess_get_exit_status() to it is
incorrect (although both encodings happe...* subprocess test: Check wait status correctly
Confusingly, g_spawn_check_exit_status() takes a wait status, not an
exit status, so passing g_subprocess_get_exit_status() to it is
incorrect (although both encodings happen to use 0 to encode success
and a nonzero value to encode failure, so in practice this probably
had the desired effect).
* Distinguish more clearly between wait status and exit status
On Unix platforms, wait() and friends yield an integer that encodes
how the process exited. Confusingly, this is usually not the same as
the integer passed to exit() or returned from main(): conceptually it's
an integer encoding of this tagged union:
enum { EXITED, SIGNALLED, ... } tag;
union {
int exit_status; /* if EXITED */
struct {
int terminating_signal;
bool core_dumped;
} terminating_signal; /* if SIGNALLED */
...
} detail;
Meanwhile, on Windows, wait statuses and exit statuses are
interchangeable.
I find that it's clearer what is going on if we are consistent about
referring to the result of wait() as a "wait status", and the value
passed to exit() as an "exit status".
GSubprocess already gets this right: g_subprocess_get_status() returns
the wait status, while g_subprocess_get_exit_status() genuinely returns
the exit status. However, the GSpawn family of APIs has tended to
conflate the two.
Confusingly, g_spawn_check_exit_status() has always checked a wait
status, and it would not be correct to pass an exit status to it; so
let's deprecate it in favour of g_spawn_check_wait_status(), which
does the same thing that g_spawn_check_exit_status() always did.
Code that needs backwards-compatibility with older GLib can use:
#if !GLIB_CHECK_VERSION(2, 69, 0)
#define g_spawn_check_wait_status(x) (g_spawn_check_exit_status (x))
#endif
* spawn: Clarify the most common non-exit reason for process termination
A reader might think "how would a process terminate without an exit
status?", or equivalently, "what harm would it do if I assume every
termination has an exit status?" without this reminder that termination
with a signal is also reasonably common.2.69.0https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2215gtestutils: Add more convenience functions2021-08-19T09:35:49ZSimon McVittiegtestutils: Add more convenience functionsBased on !2216 (without which the tests added here will fail), please review that first.
* gtestutils: Allow failing a test with a printf-style message
This allows a pattern like
g_test_message ("cannot reticulate ...Based on !2216 (without which the tests added here will fail), please review that first.
* gtestutils: Allow failing a test with a printf-style message
This allows a pattern like
g_test_message ("cannot reticulate splines: %s", error->message);
g_test_fail ();
to be replaced by the simpler
g_test_fail_message ("cannot reticulate splines: %s", error->message);
with the secondary benefit of making the message available to TAP
consumers as part of the "not ok" message.
* tests: Make use of g_test_fail_message()
* gtestutils: Allow skipping tests with a printf-style message
Forming the g_test_skip() message from printf-style arguments seems
common enough to deserve a convenience function.
g_test_incomplete() is mechanically almost equivalent to g_test_skip()
(the semantics are different but the implementation is very similar),
so give it a similar mechanism for symmetry.
* tests: Use g_test_skip_printf()2.69.2https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2429gdbus: make client work with EXTERNAL on Windows2022-01-19T18:38:22ZMarc-André Lureaugdbus: make client work with EXTERNAL on WindowsD-Bus reference implementation doesn't require more than the claimed
client process SID as part of the AUTH initial data for EXTERNAL.D-Bus reference implementation doesn't require more than the claimed
client process SID as part of the AUTH initial data for EXTERNAL.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2452gio/win32: add GMemoryMonitorWin322022-01-25T18:11:54ZMarc-André Lureaugio/win32: add GMemoryMonitorWin32Windows has CreateMemoryResourceNotification() API:
https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-creatememoryresourcenotification
It only notifies whether "Available physical memory is running low."
Helps:...Windows has CreateMemoryResourceNotification() API:
https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-creatememoryresourcenotification
It only notifies whether "Available physical memory is running low."
Helps: #1371https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2458Implement fd passing for Windows spawn2022-03-31T21:44:59ZMarc-André LureauImplement fd passing for Windows spawnThe Windows implementation was left-out for `g_spawn_async_with_pipes_and_fds ()` when introduced.
Since commit d98a52254b4a681569a44f6be2aeceeaed58202c, dbus testing requires spawning a daemon with fd passing!
Related to #1371The Windows implementation was left-out for `g_spawn_async_with_pipes_and_fds ()` when introduced.
Since commit d98a52254b4a681569a44f6be2aeceeaed58202c, dbus testing requires spawning a daemon with fd passing!
Related to #1371https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2819Bring back gio-launch-desktop, use it to redirect stdout/stderr to the Journal2022-07-25T09:59:59ZSimon McVittieBring back gio-launch-desktop, use it to redirect stdout/stderr to the Journal* !2818
* Revert "gdesktopappinfo: Use `sh` rather than `gio-launch-desktop`"
A shell one-liner was enough to set GIO_LAUNCHED_DESKTOP_FILE_PID,
but ideally we also want to do the equivalent of sd_journal_stream_fd()
t...* !2818
* Revert "gdesktopappinfo: Use `sh` rather than `gio-launch-desktop`"
A shell one-liner was enough to set GIO_LAUNCHED_DESKTOP_FILE_PID,
but ideally we also want to do the equivalent of sd_journal_stream_fd()
to set up its standard output and standard error streams.
Ideally we would call sd_journal_stream_fd() in a process that will
exec the real program, otherwise it will report the wrong process ID
in the Journal, but we can't easily do that in a forked child when
using posix_spawn() for subprocesses.
This reverts commit 2b533ca99ad07090d7090ad7389d1e85230aa618.
* tests: Avoid using deprecated meson.build_root
* gio-launch-desktop: Add SPDX-License-Identifier
* gio-launch-desktop: Fix a compiler warning
* gdesktopappinfo: Don't trust $GIO_LAUNCH_DESKTOP if setuid
gio-launch-desktop was removed before checking GIO for potentially
unsafe environment variable references, so reverting its removal brought
this one back. If a setuid program is using GAppInfo then something is
probably already horribly wrong, but let's be careful anyway.
* Install gio-launch-desktop in a non-PATH location
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).
When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.
When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.
* gio-launch-desktop: Redirect stdout, stderr to systemd Journal
This prevents a launched process's output from being mixed up with the
output of the parent process, which can lead to the wrong program being
blamed for warning messages.
and optionally (these last two are easy to drop if not wanted):
* gmessages: Factor out _g_fd_is_journal into its own translation unit
I want to use this in gio-launch-desktop, but gio-launch-desktop
doesn't depend on GLib, so I can't just call g_log_writer_is_journald().
* gio-launch-desktop: Don't alter stdout/stderr if not already the Journal
Resolves #26822.73.3Simon McVittieSimon McVittiehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2818gio: Optionally install trigger executables to architecture-specific paths2022-07-25T10:02:13ZSimon McVittiegio: Optionally install trigger executables to architecture-specific pathsIn Debian-style multiarch (libdir = lib/x86_64-linux-gnu or similar),
Red-Hat-style multilib (libdir = lib64 or lib) and Arch-style multilib
(libdir = lib or lib32), we have to run a separate version of
gio-querymodules to discover 32- o...In Debian-style multiarch (libdir = lib/x86_64-linux-gnu or similar),
Red-Hat-style multilib (libdir = lib64 or lib) and Arch-style multilib
(libdir = lib or lib32), we have to run a separate version of
gio-querymodules to discover 32- or 64-bit modules on x86. Installing
modules in the directory used for each word size needs to trigger
recompilation of the correct modules list.
Debian, Fedora and Arch currently all have patches to facilitate this:
Debian moves gio-querymodules into ${libdir}/glib-2.0 and provides a
compat symlink in ${bindir}, while Fedora and Arch rename one or both
of the gio-querymodules executables to give it a -32 or -64 suffix.
We can avoid the need for these patches by making this a build option.
Doing this upstream has the advantage that the pkg-config metadata for
each architecture points to the correct executable and is in sync with
reality.
I'm using Debian's installation scheme with a separate directory here,
because the word-size suffix used in Fedora and Arch only works for the
common case of 32- and 64-bit multilib, and does not cover scenarios
where there can be more than one ABI with the same word size, such as
multiarch cross-compilation or alternative ABIs like x32.
Now that we have this infrastructure, it's also convenient to use it for
glib-compile-schemas. This works with /usr/share, so it only needs to
be run for one architecture (typically the system's primary
architecture), but using /usr/bin/glib-compile-schemas for the trigger
would result in either primary and secondary architectures trying to
overwrite each other's /usr/bin/glib-compile-schemas binaries, or a
circular dependency (the GLib library would have to depend on a
common package that contains glib-compile-schemas, but
glib-compile-schemas depends on the GLib library). Installing a
glib-compile-schemas binary in an architecture-specific location
alongside each GLib library bypasses this problem.
Signed-off-by: Simon McVittie <smcv@collabora.com>2.73.3Simon McVittieSimon McVittiehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3013tests: Fix few new clang warnings2022-10-25T16:09:53ZMarco Trevisanmail@3v1n0.nettests: Fix few new clang warningsWe had some new warnings with recent clang, let's handle them.We had some new warnings with recent clang, let's handle them.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3027gstdio: Preserve errno in g_autofd, document async-signal safety2022-11-03T20:42:51ZSimon McVittiegstdio: Preserve errno in g_autofd, document async-signal safety* gstdio: Preserve errno when calling g_clear_fd() from g_autofd
g_clear_fd() can alter errno, but it's unexpected for leaving a scope
to change errno.
* gstdio: Document errno behaviour of g_clear_fd
g_clear_fd ha...* gstdio: Preserve errno when calling g_clear_fd() from g_autofd
g_clear_fd() can alter errno, but it's unexpected for leaving a scope
to change errno.
* gstdio: Document errno behaviour of g_clear_fd
g_clear_fd has the same interaction with errno as g_close or most libc
functions: on success it has an unspecified effect on errno, and on
failure (other than programming error) it sets errno to indicate the
reason for failure.
* gstdio: Document async-signal-safety of g_clear_fd and g_autofd
g_clear_fd wraps g_close and is async-signal-safe under essentially the
same circumstances. If fd_ptr already pointed to a negative number, then
g_clear_fd doesn't call g_close, and is still async-signal-safe.
g_autofd passes a NULL error pointer to g_clear_fd, so it is
async-signal-safe, as long as no programming error occurs.
* tests: Test EBADF and errno handling when closing fdsSimon McVittieSimon McVittie