There were tests for the situation where it does the exchange and
returns true, but no tests for the situation where it returns false.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Document that g_vasprintf and g_strdup_printf are guaranteed to return a
non-NULL string, unless the format string contains the locale sensitive
conversions %lc or %ls.
Further annotate that the output parameter for g_vasprintf and the
format string for all functions must be non-NULL.
Fixes#1622
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The g_vasprintf method is called by g_strdup_vprintf, g_strdup_printf,
g_string_append_vprintf and more. It has three different implementations
depending on what the build target platform supports:
1. The gnulib impl appears to use the system malloc, but a
'#define malloc g_malloc' causes it to use GLib's wrapper
and thus abort on OOM. This mostly gets used on Windows
platforms or UNIX platforms with broken printf formatting.
2. The main impl mostly used on modern Linux/UNIX calls the
system vasprintf which uses the system malloc and does not
abort on OOM.
3. The final impl used on remaining platforms calls system
vsprintf on a buffer allocated by g_new, and thus always
aborts on OOM.
Of note is that impl 2 (using vasprintf) historically could abort on
OOM, if the application had installed a non-system malloc impl with
GLib. This was because the code would g_strndup the result from
vasprintf() in that scenario. This was removed in:
commit a366053253
Author: Dan Winship <danw@gnome.org>
Date: Fri Aug 7 09:46:49 2015 -0400
glib: remove deprecated g_mem_is_system_malloc() check in gprintf.c
Having inconsistent OOM behaviour for the three impls is undesirable and
aborting on OOM is normal pratice for GLib APIs. Thus we must thus ensure
this happens in all impls of g_vasprintf.
Fixes#1622
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
These were introducing strict aliasing warnings. Remove them (in line
with other uses of `g_once_init_leave()`).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Casting pointer types around is a bit fiddly when you also end up
dereferencing them. Take advantage of the fact that the
`__atomic_load()` and `__atomic_store()` built-ins are polymorphic, and
use `__typeof__()` to ensure that the atomic pointer macros use the
caller-provided types internally, and hence any type mismatches are
entirely the caller’s fault rather than ours.
This also means that the `__atomic_{load,store}()` built-ins have the
right alignment and width data from the caller-provided types, in case
that’s needed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Various places that used atomic functions were using the wrong return
type. Fix that. This introduces no functional changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Mounts are currently completed only if the prefix looks like scheme,
however, this doesn't work well if the mounts have also path component.
Let's always include them to fix this issue. The mounts are cached by the
volume monitors, so it should not significantly affect the performance.
Currently, "gio mount google-drive<tab>" isn't completed even though
that volume exists for google-drive://oholy@redhat.com/. Let's use
"gio mount -li" output to complete also activation roots of volumes.
Currently, "gio list file:///h<tab>" doesn't complete "file:///home"
because the result of "dirname file:///h" is not "file:///" but "file:/",
which breaks the consequent logic. Let's subtract basename from the
path in order to workaround this issue.
Fixes build failure:
../gio/gunixmounts.c: In function ‘_g_get_unix_mounts’:
../gio/gunixmounts.c:742:53: error: ‘struct mnttab’ has no member named ‘mnt_opts’; did you mean ‘mnt_mntopts’?
742 | mntent.mnt_opts,
| ^~~~~~~~
| mnt_mntopts
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
g_date_time_add_seconds() and g_date_time_add_full() use floating-point
seconds, which can result in the value varying slightly from what's
actually on disk. This causes intermittent test failures in
gio/tests/g-file-info.c on Debian i386, where we set a file's mtime
to be 50µs later, then read it back and sometimes find that it is only
49µs later than the previous value.
I've only seen this happen on i386, which means it might be to do with
different floating-point rounding when a value is stored in the 80-bit
legacy floating point registers rather than in double precision.
g_date_time_add() takes a GTimeSpan, which is in microseconds;
conveniently, that's exactly what we get from the GFileInfo.
Bug-Debian: https://bugs.debian.org/941547
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're cross-compiling, the installed-tests are useful even if we
can't run them on the build machine: we can copy them to the host
machine (possibly via a distro package like Debian's libglib2.0-tests)
and run them there.
While I'm changing the build-tests condition anyway, deduplicate it.
Based on a patch by Helmut Grohne.
Bug-Debian: https://bugs.debian.org/941509
Signed-off-by: Simon McVittie <smcv@collabora.com>
