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;
^~~~~~~~~
This allows returning WOULD_BLOCK without allocating a GError, and
should later be used for various functions of GPollableOutputStream,
GPollableInputStream and anything else that can potentially block.
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.
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
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
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Check for over- and underflow when manipulating positions.
This makes the sequence
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
return NULL for the second call, as it should.
Closes: #1639
Calling
g_list_model_get_item (store, 0);
g_list_model_get_item (store, -1u);
does not return NULL for the second call, as it should.
This was showing up in GTK+ list model tests.
Since commit 290bb0dd, where various members of GTask were converted to
a bitfield, some of the getters:
• g_task_get_check_cancellable()
• g_task_get_return_on_cancel()
• g_task_get_completed()
have been returning truthy ints (zero or an arbitrary non-zero integer)
as boolean values, rather than the canonical boolean ints of 1 and 0.
This broke the `yield` statement in Vala, whose generated C code
compares `g_task_get_completed (…) != TRUE`. i.e. Whether the
`completed` field has a value not equal to 1.
Fix this by explicitly converting truthy ints to canonical boolean ints
in all getters.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1636
Names are a message bus feature, so it does not make sense to connect
to NameOwnerChanged when the underlying connection is not a message
bus.
Moreover, g_dbus_connection_signal_subscribe() will also enforce that
condition. Adding this extra check here is helpful to avoid a critical
warning when using GDBusProxy with peer-to-peer connections.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Right now this can only be set at construction but not read back.
That seems unnecessarily restrictive, and we'll need to read these
flags from outside of gdbusconnection.c in the next commit, so let's
just make it public.
https://gitlab.gnome.org/GNOME/glib/issues/1620
Add option to not encode resource data into the C source file
in order to embed the data using `ld -b binary`. This improves compilation
times, but can only be done on Linux or other platforms with a
supporting linker.
(Rebased by Philip Withnall, fixing minor rebase conflicts.)
Fixes#1489
This reverts commit 52bab0254a.
It silently conflicted with another commit,
90ca3b4dd0, which was merged later than
it. I’ve kept commit 90ca3b because it also frees the GError; 52bab
doesn’t.
This is my failure to rebase and test old branches before merging them,
instead of assuming that the lack of automatically detected merge
conflicts actually means there are no merge conflicts.
