And clarify that you must add a child watch or *not* use the
G_SPAWN_DO_NOT_REAP_CHILD flag, otherwise your child will become a
zombie on exit, and will not be reaped until the parent process exits.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Otherwise, we might end up returning TRUE from
g_app_info_launch_default_for_uri but with a set error parameter. This
will lead to confusing results depending on how the caller checks for
errors. Checking error != NULL indicats the call failed but checking the
return value indicates that it succeeded.
This way code that does not manually include the generated marshallers
header and wishes to build with `-Wmissing-prototypes` will not generate
a compiler warning.
https://bugzilla.gnome.org/show_bug.cgi?id=781755
There are a few places where commit 18a33f72 replaced valid (nullable)
(optional) annotations with just (optional). That has a different
meaning.
(nullable) (optional) can only be applied to gpointer* parameters, and
means that both the gpointer* and returned gpointer can be NULL. i.e.
The caller can pass in NULL to ignore the return value; and the returned
value can be NULL.
(optional) can be applied to anything* parameters, and means that the
anything* can be NULL. i.e. The caller can pass in NULL to ignore the
return value. The return value cannot be NULL.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some annotations I made while trying to debug bug #781847. They
introduce no behavioural changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reformatted the docs for G_VARIANT_TYPE_UINT64 to avoid having a
number in the beginning of the line, because apparently gtk-doc treats
that as a first element of the numbered list. The number being that
big probably makes gtk-doc to treat it as 1.
Fixed the g_variant_new_fixed_array documentation - it was partially
copy-pasted from the g_variant_get_fixed_array documentation.
The rest should be quite obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=781830
Temporarily increase the ref count of a GSource to 1 while calling its
finalize() callback, so that the finalize() implementation can call
GSource methods (like g_source_set_ready_time()) without causing
critical warnings. It’s safe to call those methods at this point, as the
source has been destroyed, but nothing has been freed.
This is an indirect way of fixing a race between GCancellable and
GCancellableSource, whereby the GCancellable::cancelled callback for the
GCancellableSource is not disconnected until the GCancellableSource’s
finalize() function is called. Previously, this meant there was a window
in which the GCancellableSource’s ref count was 0, but the ::cancelled
callback was still connected, and could legitimately be called as a
result of another thread calling g_cancellable_cancel() on the
GCancellable. The callback calls g_source_set_ready_time() on the
GSource, and there’s no thread-safe way of checking whether the GSource
has been destroyed. Instead, we have to change GSource so its ref count
is only decremented to 0 inside the locked section in
g_source_unref_internal() *after* the finalize() function has been
called, and hence after the GCancellable::cancelled callback has been
disconnected. The use of g_cancellable_disconnect() ensures that the
callback disconnection is thread safe.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781601
Since commit e4ee307 ("Do not wake up main loop if change is from same
thread", bug 761102), GMainContext uses context->owner to decide if the
event loop is being run in the current thread. However, what really
matters is the phase in the prepare/query/poll/check/dispatch sequence.
Wakeups are only needed between the end of prepare and the end of poll,
and then only if prepare found that no sources were ready.
There is no need to take threads into account, because prepare, check
and all callers of conditional_wakeup all look at the new need_wakeup
flag inside LOCK_CONTEXT/UNLOCK_CONTEXT.
With this change, g_main_context_is_owner and g_main_context_wait are
the only functions for which acquire/release matters, just like before
commit e4ee307.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Compiling with clang 3.8.1-18 (debian, x86_64) I ran across this
error:
gio-tool.c:40:31: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
message = g_strdup_vprintf (format, args);
^~~~~~
gio-tool.c:55:31: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
message = g_strdup_vprintf (format, args);
^~~~~~
2 errors generated.
To fix the first one, related with the function print_error(), this
patch adds to the function prototype a compiler's attribute.
For the second one, since the usage of that function is to print
one string and the format is already provided, the patch simplifies
the function by no receiving variadic arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=781125
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
The g_drive_is_removable() support was added recently in gio/gvfs
(see Bug 765900 and Bug 765457). It was also added in gvfs-mount,
but we forgot to add it also in gio-tool-mount.
https://bugzilla.gnome.org/show_bug.cgi?id=776169
This patch contains the following changes:
- Print all errors with "gio: " prefix
- Print file uri in error for each tool allowing multiple locations
- Mark all error messages translatable
- Do not leak strings used in error messages
- Always start error messages with capital letter
- Unify some error messages across various tools
- Fix addional/missing new line characters
https://bugzilla.gnome.org/show_bug.cgi?id=776169
This is going to be checked again by g_object_new_with_properties()
and g_object_new_valist() anyway, so might just as well leave it
to those functions to do the check and only do it once. It doesn't
matter which function emits the critical warning in the end either,
as one has to look at a stack trace to find out what code triggered
it in any case.
https://bugzilla.gnome.org/show_bug.cgi?id=780908
