This means that GLib will generate appropriate deprecation warnings if
`GLIB_VERSION_MAX_ALLOWED` has been set to target a GLib version older
than 2.58.
The timezone(3) man page on Fedora 31 describes the start/end
field in the POSIX TZ format as follows:
[quote]
The start field specifies when daylight saving time goes
into effect and the end field specifies when the change is
made back to standard time. These fields may have the fol‐
lowing formats:
Jn This specifies the Julian day with n between 1 and
365. Leap days are not counted. In this format,
February 29 can't be represented; February 28 is day
59, and March 1 is always day 60.
n This specifies the zero-based Julian day with n
between 0 and 365. February 29 is counted in leap
years.
Mm.w.d This specifies day d (0 <= d <= 6) of week w (1 <= w
<= 5) of month m (1 <= m <= 12). Week 1 is the
first week in which day d occurs and week 5 is the
last week in which day d occurs. Day 0 is a Sunday.
[/quote]
The GTimeZone code does not correctly parse the 'n' syntax,
treating it as having the range 1-365, the same as the 'Jn'
syntax. This is semantically broken as it makes it impossible
to represent the 366th day, which is the purpose of the 'n'
syntax.
There is a code comment saying this was done because the Linux
semantics are different from zOS and BSD. This is not correct,
as GLibC does indeed use the same 0-365 range as other operating
systems. It is believed that the original author was mislead by
a bug in old versions of the Linux libc timezone(3) man pages
which was fixed in
commit 5a554f8e525faa98354c1b95bfe4aca7125a3657
Author: Peter Schiffer <pschiffe@redhat.com>
Date: Sat Mar 24 16:08:10 2012 +1300
tzset.3: Correct description for Julian 'n' date format
The Julian 'n' date format counts atrting from 0, not 1.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Fixes: #1999
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The callers of parse_tz_boundary inverted the value passed
for the ignore_leap parameter. Fortunately the method impl
also had an inverted test cancelling out the first bug.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The implementation has always wrapped at 76 characters, rather than 72,
ever since it was introduced in commit 5cf8f1d4a8 in 2006. At this
stage, it’s probably best to fix the documentation rather than the
implementation.
The likely bug in the implementation is the comparison
```
(++already) >= 19
```
19 × 4 = 76, so it seems like an off-by-one error in the comparison.
What was actually wanted was 18 × 4 = 72.
Thanks to Simon McVittie for the investigation and diagnosis.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1997
Similar to 3837b83f, glibc memcpy is declared with the first two
arguments annotated as non-null via an attribute, which results in the
undefined behaviour sanitizer considering it to be UB to pass a null
pointer there (even if we are copying no bytes, and hence not actually
dereferencing the pointer).
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_atomic_pointer_compare_and_exchange() should work with const pointers.
Add a test for that.
It seems clang 9.0.0-2.fc32 does not like this:
../glib/tests/atomic.c:93:9: warning: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'const char **' [-Wincompatible-pointer-types]
res = g_atomic_pointer_compare_and_exchange (&vp_str, NULL, str);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
../glib/tests/atomic.c:96:9: warning: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'const char **' [-Wincompatible-pointer-types]
res = g_atomic_pointer_compare_and_exchange (&vp_str_vol, NULL, str);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
Note that this clang version already issues various compiler warnings for
this test. This merely adds another case to check.
Eventually g_atomic_pointer_compare_and_exchange() should be fixed to
avoid compiler warnings.
Actually there is a problem. When you try to use g_atomic_pointer_compare_and_exchange()
with const pointers, it is also not working, because the implementation
as a function expects "void *" arguments. As the test also shows. As such,
it's probably not portable to use g_atomic_pointer_compare_and_exchange()
with const pointers at all. However, the macro implementation is (with the right
compiler) fine with that, so it's an easy "mistake" to make.
Even if g_variant_get_va(), which we eventually call, checks on the
validity of the value argument, check it early to avoid surprises, such
as this intermittent FreeBSD test failure:
(/var/tmp/gitlab_runner/builds/3fe11159/0/GNOME/glib/_build/gio/tests/gdbus-connection:65788): GLib-CRITICAL **: 15:13:25.670: g_variant_get_va: assertion 'value != NULL' failed
Especially check for a valid reference count. This is possible now in
all cases because of the addition of the dispose function and makes
usage of already finalized/finalizing GSources more obvious than the
use-after-free that would otherwise happen.
This allows GSource implementors to safely clear any other references to
the GSource while the GSource is still valid, unlike when doing the same
from the finalize function.
After the dispose function has run, it is valid for the reference count
of the GSource to be > 0 again to allow the case where another thread in
the mean-time got access to the GSource reference before the dispose
function was called.
This allows fixing a thread-safety issue in the GCancellable, GstBus and
various other GSource implementations.
When compiling a program using glib with -Wzero-as-null-pointer-constant
warnings enabled, the compiler warns about this type check in the
g_once_init_enter macro. Fix by replacing "0" with "NULL".
This is a convenience wrapper around getpwnam_r() which handles all the
memory allocation faff.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1687
Although not quite as often-occurring, this should help with constructs
like this:
if (list)
{
g_list_free_full (list, foo);
list = NULL;
}
Closes https://gitlab.gnome.org/GNOME/glib/issues/1943
In C, the proper type for a heap allocate structure is size_t/gsize.
That means, no valid (heap allocated) pointer will ever contain more
bytes than size_t can represent.
Hence, this integer type should also be used when operating on
data like a strv array. Adjust some internal uses to use gsize
instead of gint/guint.
Note that g_strv_length() returns a value of type guint. So this
API cannot be used on string arrays longer of arbitrary size. But
that is not fixable.
This reverts commit fd3ed5e31bc0d3d6a0a34d6482bb2ae10f186c06.
C11-style atomics have been fixed (on FreeBSD and other platforms) in
the previous commit, “gatomic: Check argument width in
g_atomic_pointer_compare_and_exchange()”.
See !1229 and #1940.
Check that the new value is actually pointer-width, rather than (for
example) `sizeof (int)` which could happen if someone used `0` rather
than `NULL`.
Changes suggested by Simon McVittie.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1940
Don’t pass integers; it’s not type-safe. The macro version of
`g_atomic_pointer_compare_and_exchange()` used to erroneously accept
integers, but they would have the wrong width on some platforms.
Changes originally investigated and suggested by Ting-Wei Lan.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1940
They’re causing the CI to fail. While someone familiar with FreeBSD
investigates the failure, it’s easiest to disable all C11-style atomics
than add more preprocessor checks to only disable the atomics added in
!1123.
If nobody can fix the new C11-style atomics before the 2.64.0 release,
this commit should be reverted and a more comprehensive set of preprocessor
checks put in place to essentially revert !1123 for BSD only.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1940
In glib/gutf8.c there was an UB in function g_utf8_find_prev_char when
p == str. In this case we substract one from p and now p points to a
location outside of the boundary of str. It's a UB by the standard.
Since this function are meant to be fast, we don't check the boundary
conditions.
Fix glib/tests/utf8-pointer test. It failed due to the UB described
above and aggressive optimisation when -O2 and LTO are enabled. Some
compilers (e.g. GCC with major version >= 8) create an optimised version
of g_utf8_find_prev_char with the first argument fixed and stored
somewhere else (with a different pointer). It can be solved with either
marking str as volatile or creating a copy of str in memory. We choose
the second approach since it's more explicit solution.
Add additional checks to glib/tests/utf8-pointer test.
Closes#1917
Commit 7678b107 seems to have left the GHashTable pretty printer with an
off-by-one error, skipping the first key it encounters and printing an
extra garbage key/value pair instead. This fixes that by moving an
increment to the end of a loop rather than the beginning.
