As per commit a5390002 we're exiting with error in case fgets failed,
however it could also fail because of EOF (like on ^D), so in such case
we can just return early treating it as a non-error.
Otherwise still exit with error.
Fixes: #2737
* Remove an unneeded field from LaunchUrisData and add annotations
* Rename local GError* variables to local_error
* Use g_set_object
* Fix indentation
...of the application if many URI's are provided. This is important to note
because the GAppLaunchContext signals may be emitted multiple times during
a single launch operation.
We cannot cancel a spawn operation, but sometimes we have to
spawn the target application mutiple times (e.g. in case the
target app only supports one URI in its command-line, but we
were given multiple URI's), in that case continuously check
the cancellation status before attempting any spawn operation
First, there's no reason not to use the new `epoll_create1` system call,
which quickly obsoleted `epoll_create` which has an obsolete and
unused size argument.
But more specifically, it offers `EPOLL_CLOEXEC` which we want
to use for general hygeine - there's no reason to potentially
leak this file descriptor to forked processes.
(GLib itself carefully closes file descriptors when forking child
processes, but it may be linked with other software that doesn't;
notably in my case for example the Rust standard library does not
do this and hence relies more on the application code using
`O_CLOEXEC` and variants)
This is just a drive-by fix; I saw the system call when I was using
`strace` to debug something else in rpm-ostree.
GParamSpec nicks and blurbs are effectively a deprecated feature,
or at least unused by most libraries these days. Since a number
of C libraries (i.e. GTK4) have started to null these out, annotate
them as `(nullable)` so bindings can do the same.
Closes#2719
For all the memory allocator APIS, document
that they terminate the program on failure.
This was so far only mentioned in the long description,
and in the docs for g_try_malloc(). And with gi-docgen
style docs, the long description is going away.
This utility function will be called by both launch_uris and
launch_uris_async, passing a from_task parameter respectively
as NULL and non-NULL. The from_task parameter will be needed
to know whether GAppLaunchContext signals should be emitted
directly (from_task == NULL) or scheduled for emission on the
main thread (from_task != NULL).
All of these warnings indicate programmer error, so critical is most
appropriate here.
Exceptions: deprecation warnings are just warnings. Also, warnings that
are worded with uncertainty can remain warnings rather than criticals.
