It isn't always obvious how and where to use these. Where possible I've
chosen real examples from GLib, preferring simple examples that
developers considering using these macros have hopefully already seen.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If using the --interface-info-{body,header} options to gdbus-codegen,
and the first interface to be outputted has no methods, but does have
properties or signals, an uninitialised variable would be used for the
property/signal ‘since’ values.
In other situations, the ‘since’ value for a prior method would have
been incorrectly used for the properties/signals.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
nm_conn_to_g_conn already handles UNKNOWN like NONE (returning
G_NETWORK_CONNECTIVITY_LOCAL in both cases). So in sync_properties
we should also set new_connectivity to G_NETWORK_CONNECTIVITY_LOCAL
for both NM_CONNECTIVITY_UNKNOWN and NM_CONNECTIVITY_NONE.
This has the added benefit that when NetworkManager returns the network
connectivity is UNKNOWN, we set network_available to FALSE as it should
be. Previously, there were cases in a laptop with no network access,
that g_network_monitor_get_network_available returned true, which was
wrong and is also fixed with this commit.
We want GLib to build correctly with this defined, and for all its tests
to still pass.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1708
Both GCC and Clang treat this as a hint that the code won’t be reached,
which helps in the cases where they might not have automatically
detected it already.
It doesn’t change any behaviour of the compiled code, other than
allowing the compiler to go off into undefined behaviour.
See
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005funreachable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to allow GLib itself to be built with G_DISABLE_ASSERT defined,
we need to explicitly undefine it when building the tests, otherwise
g_test_init() turns into an abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1708
Move them next to their definitions, so they’re more likely to be kept
up to date.
This doesn’t modify any of the documentation comments at all.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative error messages on failure, and can’t
be disabled by G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Any function which requires g_quark_init() to have been called first
cannot be called before the library constructors have finished running.
In particular, this means that g_quark_from_static_string() or
g_intern_static_string() can’t be used to initialize C++ globals.
Do this, rather than adding a conditional call to g_quark_init() to all
these functions, because such a call was previously removed from the
functions to improve performance (quarks are used a lot in the
implementation of GObject for properties and signals). That’s the reason
why g_quark_init() was originally moved out to a library constructor.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1177
g_object_set_data() should only ever be used with a small, bounded set
of keys, or the memory usage of the quark lookup table will grow
unbounded. Document that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #682
Those lists were getting very long. We can’t quite entirely automate the
list generation since Meson doesn’t have a range() function, but we can
at least combine three of them into one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>