PEP8 says that:
"Comparisons to singletons like None should always be done with is or
is not, never the equality operators."
glib uses a mix of "== None" and "is None". This patch changes all
cases to the latter.
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__().
If G_DISABLE_ASSERT is defined, g_assert() is a no-op. Despite it now
being standard practice to *not* use g_assert() in unit tests (use
g_assert_*() instead), a lot of existing unit tests still use it.
Compiling those tests with G_DISABLE_ASSERT would make them silently
no-ops. Avoid that by warning the user loudly.
Note that it’s pretty rare for people to compile with G_DISABLE_ASSERT,
so it’s not expected that this will be hit often.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/976
g_assert() must not be used in tests. g_assert_*() must not be used in
production code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/976
Use g_test_skip() so that the TAP output is correct for the tests,
rather than printing using g_printerr().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/640
If the fileutils test was run in a directory which is a symlink (for
example, on macOS, /tmp is often a symlink to /private/tmp), a path
comparison was failing. Compare the paths as inodes instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/889
Type punning is used on the existing implementation, which hides errors
such as:
GSList *list = NULL;
g_clear_pointer (&list, g_error_free);
Let's use __typeof__ to cast the passed-in pointer before it's passed to
the free function so it trips -Wincompatible-pointer-types if it's wrong.
Fixes#1425
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.
