These are needed to get `SIZE_WIDTH` from libc. The tests which used
`SIZE_WIDTH` were previously effectively dead code. Spotted by
`-Wundef`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`G_HAS_CONSTRUCTORS` is defined to 1, or not defined at all. It’s never
defined to 0. Follow the GLib conventions and use `#ifdef` rather than
`#if`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There is no `G_HAS_DESTRUCTORS` `#define` and there never has been: the
presence of destructors is indicated by `G_HAS_CONSTRUCTORS` (one is
never supported without the other).
Spotted by `-Wundef`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Since we copy the libcharset code in, it makes use of a few defines
which our build system didn’t previously define. Hook those up in
`meson.build` rather than changing the code (even though some of it’s
dead code) so we don’t diverge from upstream libcharset.
This helps with `-Wundef` support.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The alternative is to `#define` all the `G_CREDENTIALS_*` defines to
zero in each platform’s definition block, which would result in a
combinatorial explosion of `#define`s (or loads of `#undef`s).
Stick to the convention for GLib and consistently define them to 1 or
leave them undefined.
This helps with `-Wundef` support.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We prefer `#ifdef` to `#if` in code, so let’s use the `-Wundef` warning
to enforce that. In CI, `-Werror` is enabled, so this should be
enforcement enough.
Suggested by Thomas Haller.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The proper, documented way to check for debug mode is "#ifdef G_ENABLE_DEBUG",
not "#if G_ENABLE_DEBUG".
$ git grep -l '# *if \+G_ENABLE_DEBUG' | xargs sed 's/#if \+G_ENABLE_DEBUG/#ifdef G_ENABLE_DEBUG/g' -i
This (and other such errors) would be caught by "-Wundef", which CI
probably should run.
$ CFLAGS="-Werror=undef" meson build -Dglib_debug=disabled && ninja -C build -k 0
Make it a bit clearer that a returned `GFileInfo` can be empty if
`stat()` fails (e.g. with `EACCES`), and that it’s the caller’s
responsibility to use `g_file_info_has_attribute()` before retrieving
attribute values.
This better documents what we implemented in, for example, !3336.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3658
It probably would get inlined anyway(?). But add G_ALWAYS_INLINE
to be more sure about this. We don't want this mostly trivial
function to be a separate call.
These are similar to g_pointer_bit_lock_and_get() and
g_pointer_bit_unlock_and_set().
The bitlock API is pretty amazing, as it allows to use a single bit of
an integer for locking while using the remaining 31 bits for other
purposes. But those other bits always need to be accessed atomically
too.
There is a use in being able to lock_and_get(), to combine the setting
of the lock bit and fetching the new value at once. For one, that can
safe additional atomic operations to fetch the value afterwards. But
more importantly, it allows to do this change in one atomic operation.
Likewise, unlock_and_set() allows to atomically clear the lock bit and
set a new value (while also preserving unrelated bits, by using the
@preserve_mask parameter).
With the previous changes, all accesses to the WeakRefStack go through
g_datalist_id_update_atomic() and are guarded by the GData's bit lock.
At this point, the OPTIONAL_BIT_LOCK_WEAK_REFS lock is unnecessary and
can be dropped.
A minor benefit is that g_object_weak_{ref,unref}() needs now one lock
less.
Also note that this rework fixes a potential race for weak refs. Note
that we have two calls
g_datalist_id_set_data (&object->qdata, quark_weak_notifies, NULL);
that don't take OPTIONAL_BIT_LOCK_WEAK_REFS lock. One of these calls is
right before finalize(). At that point, no other thread can hold a
reference to the object to race and we are good. However, the other call
is from g_object_real_dispose(). At that point, theoretically the object
could have been resurrected and a pointer could have been passed to
another thread. Calling then g_object_weak_ref()/g_object_weak_unref()
will race. We would have required a OPTIONAL_BIT_LOCK_WEAK_REFS lock
around those g_datalist_id_set_data(,,NULL) calls.
Instead, this is now also fixed, because every update to the
WeakRefStack happens while holding the GData lock. So if you call
g_datalist_id_set_data(,,NULL), the WeakRefStack is removed from the
GData (and later freed by weak_refs_notify() and can no longer
concurrently updated by g_object_weak_{ref,unref}().
This is a step step to drop OPTIONAL_BIT_LOCK_WEAK_REFS lock. See the
next commits why that is done.
Also, free the WeakRefStack, if there are no more references.
Previously, it was never freed.
The usual macro for Linux is `__linux__`, not `__LINUX__`. Noticed this
after Ruby fixed a similar error (6fbc32b5d0da31535cccc0eca1853273313a0b52).
Fixes: 5b84636e62d2c77ad4fee49742750a3df762736c
Spotted while looking at CI output for the previous commit, and I
thought I might as well fix it while I was there.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This should fix compile errors on macOS, which couldn’t find the
`write()`, `lseek()`, etc. functions added in commit
020e58bac53e2d06e27cb1ab85d488e743abe9b4.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It was always passed the same value by all users of the macro.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than atomically querying the flags, and then atomically reffing
the `GClosure`, do the atomic ref and return the new flags value as a
side-effect. This eliminates the need for an additional atomic read, and
eliminates a race window between the two accesses.
It does mean we need a new internal version of `g_closure_ref()` which
returns the new `GClosureFlags` though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Remove the last few non-atomic reads of `GClosure.ref_count`. See
previous commits for an explanation of why this is important.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Currently, `GClosure` does atomic writes to the flags in its initial
bitfield, but it never does atomic reads from them. This is not safe —
even if the memory read for an int is atomic, the compiler might
duplicate or rearrange a non-atomic read and give an unexpected result.
Using an atomic fetch inserts the necessary compiler and hardware
barriers to ensure a single result is fetched.
(See !4575 of an example of where this kind of bug has caused
misbehaviour.)
So, introduce an atomic read helper for the `GClosure` bitfield. Rather
than reading a single member of the bitfield, it returns the entire
bitfield, as several `GClosure` methods need access to multiple members
of the bitfield, and atomically fetching them all separately would not
be atomic overall.
Fix various `GClosure` methods to use the new atomic read function.
There are more parts of the code still to fix — these were just the
straightforward ones.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Depending on luck, g_closure_ref may access closure->vint and observe
different values between reads. This manifests as a test failure in
signals-refcount{2,4}, properties-refcount1, and closure-refcount depending
on timing and re-runs.
Jakub Jelinek analysed this on GCC bug PR119607 after I'd reported it
over there as a possible GCC regression.
The critical part being g_closure_ref -> ATOMIC_INC_ASSIGN -> ATOMIC_CHANGE_FIELD
where closure->vint gets re-read repeatedly, both outside and inside the retry
loop. To fix that:
1. Atomically fetch it the first time;
2. Use the cached read, not a fresh read, of vint in the loop;
3. Use g_atomic_int_compare_and_exchange_full in the loop so we get a freshly
cached vint if it changed in another thread.
Bug: https://gcc.gnu.org/PR119607
Fixes: 834ddd19 ('turned all modifications to the first 32 integer bits in a closure into')
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
`GDate` currently has some API which is specific to which day of the week
you think the week starts on:
* `g_date_get_monday_week_of_year()`
* `g_date_get_monday_weeks_in_year()`
* `g_date_get_sunday_week_of_year()`
* `g_date_get_sunday_weeks_in_year()`
This is to deal with the difference between locales which think that the
week starts on a Sunday (such as `LANG=en_US.utf8` or `LANG=he_IL.utf8`),
or a Monday (such as `LANG=en_GB.utf8`).
However, there are some locales which think that the week starts on a
Saturday (such as `LANG=ar_EG.utf8`). Currently, GLib provides no API for
those.
So, add some API which is parameterised by the first day of the week,
which will deal with weeks which start on a Saturday (and also any other
day of the week, although I don’t believe there are any countries which
use a day other than Saturday, Sunday or Monday).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3617
