It would always be initialized but initialize it to NULL to silence the
compiler, and also check that it is not NULL anymore when we expect it
to contain a valid value.
../gio/tests/desktop-app-info.c: In function ‘test_fallback’:
../gio/tests/desktop-app-info.c:191:18: warning: ‘app’ may be used uninitialized in this function [-Wmaybe-uninitialized]
g_assert_true (g_app_info_equal (info1, app));
^~~~~~~~~~~~~~~~
It could've never been uninitialized in this code but the code flow is
not obvious to the compiler. Initialize it to NULL and for clarity also
add an assertion that it is not NULL anymore on usage.
In file included from ../glib/glib.h:62,
from ../gobject/gbinding.h:28,
from ../glib/glib-object.h:23,
from ../gio/gioenums.h:28,
from ../gio/giotypes.h:28,
from ../gio/giomodule.h:28,
from ../gio/giomodule.c:25:
../gio/giomodule.c: In function ‘_g_io_module_get_default’:
../glib/gmessages.h:343:25: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define g_debug(...) g_log (G_LOG_DOMAIN, \
^~~~~
../gio/giomodule.c:912:17: note: ‘extension’ was declared here
GIOExtension *extension, *preferred;
^~~~~~~~~
Interpret the value "help" for environment variables that
are passed to _g_io_module_get_default(), and print the
names and priorities of available extensions.
This lets users explore what is available, and can be helpful
in figuring out why a certain extension was chosen as default.
It is similar in spirit to what we already do with environment
variables like G_DEBUG.
They’re out of date. Probably best to leave the document unsigned, since
it’s supposed to be endorsed by all the GLib maintainers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is useful for debugging in many situations. It’ll be printed with
G_MESSAGES_DEBUG=GLib-GIO or G_MESSAGES_DEBUG=all.
Mostly I need it for debugging the default GNetworkMonitor, but it will
work for all GIO module implementations.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When we are in a sandboxed situation, bump the priority
of the keyfile settings backend above the dconf one,
so we use a keyfile inside the sandbox instead of requiring
holes in the sandbox for dconf.
Stacked databases and locks are dconf features that allow
management software like Fleet Commander to set system-wide
defaults and overrides centrally for applications.
This patch adds minimal support for the same to the keyfile
backend. We look for a keyfile named 'defaults' and a
lock-list named 'locks'.
Suitable files can be produced from a dconf database with
dconf dump and dconf list-locks, respectively.
The default location for these files is /etc/glib-2.0/settings/.
For test purposes, this can be overwritten with the
GSETTINGS_DEFAULTS_DIR environment variable.
Writes always go to the per-user keyfile.
Make it possible to instantiate a keyfile settings backend
without specifying parameters, by turning the arguments to
the new() function into construct-only properties. If no
filename is specified, default to
$XDG_CONFIG_HOME/glib-2.0/settings/keyfile
Rather than prefixing unsigned numbers with unary minus operators and
expecting the implicit cast to carry the correct value through, add an
explicit cast to a signed type before the unary minus is applied.
In all four cases, an overflow check has already been done.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1655
It needs investigating and fixing properly, but let’s not let it disrupt
the CI in the meantime.
Follow-up in https://gitlab.gnome.org/GNOME/glib/issues/1653.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than storing it as an invalid value in last_position, store it as
a separate boolean.
This introduces no functional changes, but should fix some warnings from
MSVC.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1500
The subprocess needs to access the test_log_fd. If the file descriptors
are not left open, functions such as g_test_message may stomp on file
descriptors open by the subprocess and cause bad behavior of the test.
(Tweaked by Philip Withnall <bugzilla@tecnocode.co.uk> to fix review
comments.)
In C++ we can use nullptr to ensure g_assert_[non]null() is only called
with pointers. This will introduce build failures in tests that would
have previously compiled, but only in C++, and only for code that
misused these macros. Code using the macros properly will be fine.
This change caught a couple bugs in WebKit's API tests, where I had
accidentally used these functions improperly. E.g. this is now a build
failure in C++:
g_assert_null(webkit_context_menu_get_n_items(menu)); /* Oops! */
Either I wanted to use cmpuint there, or I wanted to use
webkit_context_menu_get_items() to receive a GList* instead.
Another example that will no longer build in C++:
g_assert_null(0); /* Contrived, but 0 is not a pointer! */
