The implementation is silently discarding this anyway, and
g_object_unref() is using atomic operations. So this should be safe.
Having this here triggers -Wdiscarded-qualifiers when g_clear_pointer()
is fixed to use __typeof__().
When compiling third-party projects with -Wbad-function-cast, the inline
g_atomic_pointer_get() implementation which uses C11 __atomic_load*()
calls on GCC was causing compilation errors like:
error: cast from function call of type ‘long unsigned int’ to non-matching type ‘void *’
While we don’t want to compile all of GLib with -Wbad-function-cast, we
should support its headers being included in projects which do enable
that warning.
It doesn’t seem to be possible to cast away the warning (e.g. by casting
the function’s result through (void)), so we have to assign to an
intermediate integer of the right size first.
The same has to be done for the bool return value from
__sync_bool_compare_and_swap(). In that case, casting from bool to
gboolean raises a -Wbad-function-cast warning, since gboolean is
secretly int.
The atomic tests have been modified to enable -Wbad-function-cast to
catch regressions of this in future. The GLib build has conversely been
modified to set -Wno-bad-function-cast, just in case people have it set
in their environment CFLAGS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1041
A lot of GLib APIs provide a string length and explicitly say that the strings
are not NUL terminated. For instance, parsing XML using GMarkupParser or
reading packed binary strings from mmapped data files.
Use either g_get_real_time() or g_date_time_new_now_local(). This means
we don’t need to worry about time_t being 32b in future (the year 2038
problem), and it makes the need for error handling a bit more explicit.
Improve the error handling in several cases.
Based on a patch by Niels De Graef
(https://gitlab.gnome.org/GNOME/glib/merge_requests/142).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1402
Apparently this is needed for building PE libraries. It makes no
difference on Linux, where linking of the GLib symbols in the inotify
file monitor code is done lazily.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1201
The accepted behaviour for reference counting functions can be described
as such:
- acquire: takes a pointer to a memory area and returns the same
pointer with its reference count increased; this means that the
returned value's ownership is fully transfered from the callee
to the caller
- release: takes a pointer to a memory area and drops the reference
count; this means that the caller transfers the ownership of the
argument to the callee
These annotations are mostly meant for documentation purposes: high
level language bindings are unlikely to use them, as they have their own
reference counting semantics on top of GLib's own, and they should not
expose this API to their own consumers.
The global hash table we use for interned strings should not own a
reference on the strings themselves, as otherwise we'd leak them all
over the place.
Instead, it should keep a "weak" reference to them; once the last
strong reference goes away, we drop remove the weak reference from the
hash table.
Both g_rc_box_release_full() and g_atomic_rc_box_release_full() should
allow passing NULL as the clear function, to conform to the existing
coding practices in GLib.
Additionally, this allows us to reimplement release() in terms of
release_full(), and improve test coverage.
The last part of the reference counting saga.
Now that we have:
- reference counter types
- reference counted allocations
we can finally add reference counted strings using reference counted
allocations to avoid creating a new String type, and reimplementing
every single string-based API.
It's more useful to have a dup() function that copies any blob of memory
into a reference counted allocation, than to have a dup() that only
copies a reference counted allocation.
GArcBox is the atomic reference counting version of GRcBox. Unlike
GRcBox, the reference acquisition and release on GArcBox are guaranteed
to be atomic, and thus they can be performed from different threads.
This is similar to Rust's Arc<Box<T>> combination of traits.
It is useful to provide a "reference counted allocation" API that can
add reference counting semantics to any memory allocation. This allows
turning data structures that usually are placed on the stack into memory
that can be placed on the heap without:
- adding a public reference count field
- implementing copy/free semantics
This mechanism is similar to Rust's Rc<Box<T>> combination of traits,
and uses a Valgrind-friendly overallocation mechanism to store the
reference count into a private data segment, like we do with GObject's
private instance data.
