On closer reading of `man 3 timezone`, it’s actually permissible for
`TZ` to contain an absolute path which points to a tzfile file outside
the system time zone database. This is indeed what happens when building
GLib under Fedora’s toolbox, so relax that check in the tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There are a lot of Unix-like systems which have not implemented the
os-release spec. On such system, we can use POSIX uname function as a
fallback to get basic information of the system.
/etc/os-release is a spec designed for Linux. While other OSes can
implement it, it doesn't make sense to use Linux as the default value
on systems which don't use Linux.
Most of the info returned is static, the only thing that changes
is the OS version.
This code relies on g_win32_check_windows_version() providing
accurate information (hopefully, MS won't nix RtlGetVersion() on
which we use for that) and supplements it with information from the
registry for Windows >= 8.1.
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");
os-release(5) is widely implemented on Linux, but not necessarily
ubiquitous: unusual or minimal Linux distributions might not have it.
It could in principle be implemented by any other Unix OS, but in
practice this has not yet happened.
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1906
Fixes: 349318e8 "gutils: Add g_get_os_info()"
Signed-off-by: Simon McVittie <smcv@collabora.com>
As an unsigned integer, this variable is always greater than or equal to
zero. Fixes a compiler warning on Android.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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 a3660532535f92cfac136435579ed4f23231f48c
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>
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>
`man dup2` says that on Linux, dup2() can return `EBUSY` if the
operation needs to be retried (in addition to returning `EINTR` in other
cases where it needs to be retried).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
All uses of fdwalk in gspawn are between fork and exec, which means only
async-signal safe functions can be called if the parent process has
multiple threads. Since fdwalk is not a standard API, we should not
assume it is safe to use unless the manual of the system explicitly says
it is async-signal safe.
Fixes: #1638
See the mailing list thread <https://lists.fedoraproject.org/archives/list/
devel@lists.fedoraproject.org/thread/SZ676IHHSLOQD6UN2I5J5VKXJ5P5SOVO/>
"glib-2.0 G_CONST_RETURN causing GCC 'warning: const' on F31", where the GCC
diagnostic
> test.c:2:13: warning: const
> 2 | G_CONST_RETURN char * f();
> | ^~~~~~~
had confused me, and "Deprecated pre-processor symbol, repace with const" is
probably a better warning message than just "const".
(That recent GCC only prints "Deprecated pre-processor symbol, repace with "
appears to be a bug in GCC that GLIB_UNAVAILABLE_MACRO already suffers from,
too. Recent Clang correctly prints "Deprecated pre-processor symbol, repace
with const".)
Previously we used the old `__sync_fetch_*()` intrinsics for some of the
atomic operations, such as `g_atomic_int_compare_and_exchange()`. When
available, use the new `__atomic_*()` intrinsics for those instead.
As with the rest of our use of `__atomic_*()` intrinsics, we use the
`__ATOMIC_SEQ_CST` memory model. If people want to use a less
restrictive memory model to get better performance in certain
situations, they can use the compiler intrinsics directly themselves.
`g_atomic_*()` aim to be as fast as possible while remaining general
purpose.
Tested using:
```
meson test --repeat 1000 atomic atomic-test
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1750
Android is emitting `-Wtautological-constant-out-of-range-compare`
warnings when compiling the validation functions for the enum types for
`GDate`. Fix that by comparing as integers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It was possible to pass in (for example) an invalid year to
g_date_time_new_week(), which would be passed on to g_date_time_new(),
which would (correctly) return `NULL` — but then
g_date_time_get_week_number() would try to dereference that.
Includes a test case.
oss-fuzz#17648
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the compiler doesn’t provide modern (C++11) atomic builtins (which is
now quite unlikely), we implement our own using the `__sync_synchronize()`
memory barrier. As Behdad and others have pointed out, though, the
implementation didn’t follow the same semantics as we use with the C++11
builtins — `__ATOMIC_SEQ_CST`.
Fix the use of memory barriers to provide `__ATOMIC_SEQ_CST` semantics.
In particular, this fixes the following common pattern:
```
GObject *obj = my_object_new ();
g_atomic_pointer_set (&shared_ptr, obj);
```
Previously this would have expanded to:
```
GObject *obj = my_object_new ();
*shared_ptr = obj;
__sync_synchronize ();
```
While the compiler would not have reordered the stores to `obj` and
`shared_ptr` within the code on one thread (due to the dependency
between them), the memory system might have made the write to
`shared_ptr` visible to other threads before the write to `obj` — if
they then dereferenced `shared_ptr` before seeing the write to `obj`,
that would be a bug.
Instead, the expansion is now:
```
GObject *obj = my_object_new ();
__sync_synchronize ();
*shared_ptr = obj;
```
This ensures that the write to `obj` is visible to all threads before
any write to `shared_ptr` is visible to any threads. For completeness,
`__sync_synchronize()` is augmented with a compiler barrier to ensure
that no loads/stores can be reordered locally before or after it.
Tested by disabling the C++11 atomic implementation and running:
```
meson test --repeat 1000 atomic atomic-test
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1449
`g_assert_*()` provide more useful failure messages, and aren’t compiled
out when building with `G_DISABLE_ASSERT`, unlike `g_assert()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When compiling GLib with `-Wsign-conversion`, we get various warnings
about the atomic calls. A lot of these were fixed by
3ad375a629c91a27d0165a31f0ed298fd553de0a, but some remain. Fix them by
adding appropriate casts at the call sites.
Note that `g_atomic_int_{and,or,xor}()` actually all operate on `guint`s
rather than `gint`s (which is what the rest of the `g_atomic_int_*()`
functions operate on). I can’t find any written reasoning for this, but
assume that it’s because signedness is irrelevant when you’re using an
integer as a bit field. It’s unfortunate that they’re named a
`g_atomic_int_*()` rather than `g_atomic_uint_*()` functions.
Tested by compiling GLib as:
```
CFLAGS=-Wsign-conversion jhbuild make -ac |& grep atomic
```
I’m not going to add `-Wsign-conversion` to the set of default warnings
for building GLib, because it mostly produces false positives throughout
the rest of GLib.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1565
Instead of calling close or fcntl on all possible file descriptors,
which is slow on systems with very high limit or even no limit on open
file descriptors, we can use closefrom or fcntl with F_CLOSEM to close
all unwanted file descriptors with a single system call.
This change only improves the performance when GSpawnChildSetupFunc is
NULL because there are applications known to abuse GSpawnChildSetupFunc
to unset FD_CLOEXEC on file descriptors. Since the change mentioned
above requires closing file descriptors directly, it cannot be used when
the caller may want to keep some of them open.
This patch was written by Sebastian Schwarz <seschwar@gmail.com> and
uploaded to https://gitlab.gnome.org/GNOME/glib/merge_requests/574.
It was later modified by Ting-Wei Lan <lantw@src.gnome.org> to address
code review issues.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1638
While the introspection scanner can glean the transfer rule for the
return values by looking at their constness, adding an explicit
annotation has the advantage of gtk-doc writing out the transfer rule as
an additional bit of documentation, making the life of the documentation
reader easier.
