scan-build thinks that it’s possible for `read_netlink_messages()` to
return `FALSE` and an unset error (or `TRUE` and a set error), and this
belief causes it to emit warnings for code which calls
`read_netlink_messages()`.
That’s not possible, but the function is written in such a way that
following the control flow would be hard for a static analyser. It would
have to work out that `retval` and `local_error == NULL` are identical
on all control flow branches.
Avoid the need for such complex analysis by eliminating `retval` and
just using `local_error` throughout.
This introduces no functional changes to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
scan-build thinks that `term_arg` could be used uninitialised. I think
there isn’t a bug here because that use is protected by the
`found_terminal == NULL` check and early return. But perhaps that logic
is a bit too complex for static analysis, so add a default value for the
variable.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
The previous approach was to return a length as a `gssize`, with
negative values indicating failure. That works fine, but causes a lot of
signed/unsigned comparisons or assignments.
Tidy the code up by splitting success from length, returning success as
a boolean, and length as a `size_t*` out argument. This introduces no
functional changes, but does tidy the code up and fix some compiler
integer warnings.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Basically various trivial instances of the following MSVC compiler
warning:
```
../gio/gio-tool-set.c(50): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Looks like the original author mixed up where the link label and the
link URL goes. :p
Previously the link would point to "https://docs.gtk.org/gio/file
attributes", with a space and no file extension.
This will become confusing when we start tracking the owner of a
well-known-name sender, and it's redundant anyway. Instead, track the
1 bit of data that we actually need: whether it's a well-known name.
Strictly speaking this too is redundant, because it's syntactically
derivable from the sender, but only via extra string operations.
A subsequent commit will add a data structure to keep track of the
owner of a well-known-name sender, at which point this boolean will
be replaced by the presence or absence of that data structure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional change, just removing some nesting. The check for whether
signal_data->subscribers is empty changes from a conditional that tests
whether it is into an early-return if it isn't.
A subsequent commit will add additional conditions that make us consider
a SignalData to be still in use and therefore not eligible to be removed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
No functional changes, except that the implicit ownership-transfer
for the rule field becomes explicit (the local variable is set to NULL
afterwards).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Subsequent changes will need to access these data structures from
on_worker_message_received(). No functional change here, only moving
code around.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using these is a bit more clearly correct than repeating them everywhere.
To avoid excessive diffstat in a branch for a bug fix, I'm not
immediately replacing all existing occurrences of the same literals with
these names.
The names of these constants are chosen to be consistent with libdbus,
despite using somewhat outdated terminology (D-Bus now uses the term
"well-known bus name" for what used to be called a service name,
reserving the word "service" to mean specifically the programs that
have .service files and participate in service activation).
Signed-off-by: Simon McVittie <smcv@collabora.com>
On GNOME/glib#3268 there was some concern about whether this would
allow an attacker to send signals and have them be matched to a
GDBusProxy in this situation, but it seems that was a false alarm.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This somewhat duplicates test_connection_signals(), but is easier to
extend to cover different scenarios.
Each scenario is tested three times: once with lower-level
GDBusConnection APIs, once with the higher-level GDBusProxy (which
cannot implement all of the subscription scenarios, so some message
counts are lower), and once with both (to check that delivery of the
same message to multiple destinations is handled appropriately).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The recently added libmount-based unix mount monitoring may fail when the
device exceeds inotify limits. Let's fallback to the older implementation
in case of the `mnt_monitor_get_fd` function failure. This among others
fixes tracker-miners failures caused by seccomp rules.
Fixes: https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/315
This is a partial revert and rework of commit
c79575362eeb8f8d24cd2c141928d7d8f22eeb94, for the `gsettings` script
only (the other completion scripts are fine).
I blindly added quoting to everything shellcheck told me to, without
testing it properly.
As it turns out, the `$schemadir` argument to `gsettings` invocations
was deliberately not quoted, so that it would expand to zero arguments
if unset, and two arguments (`--schemadir /some/path`) if set earlier in
the command-being-completed.
Quoting it meant that it expanded to one argument (the empty string) if
unset, which caused the `gsettings` subcommands to fail, and hence any
further tab completion to fail.
Fix that as suggested on https://www.shellcheck.net/wiki/SC2086 by
turning `schemadir` into an array, which either has zero members if
unset, or two members if set.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The copyright entries come from looking at `git log gio/completion/*`
and, in particular, `git log -- gio/gsettings-bash-completion.sh` (etc.)
as the files were moved after being originally written, and haven’t
really changed since.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
As suggested by Ville Skyttä in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4012#note_2084405,
make sure to invoke the copy of the command which is being completed
when asking for completions of a given subcommand.
This avoids accidentally invoking any old `gdbus`/`gresource`/etc.
binary which is hanging around in another part of `$PATH`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The copyright from `git log gio/inotify/meson.build` is now included in
the file header. The following commits are too trivial to be
copyrightable:
- d10be6102f28e63f5d85c9d8500af28dff2b7ca7
- 03e86d000fee7f59e793f7367f9db510a209b30a
- 1741fc2c6eb8e11f4e786ccc5c19c0da327630a5
- 8733d172a39a890f87f61579872c1aeba7c5e4c4
The file was contributed while the `COPYING` file for GLib was
LGPL-2.1-or-later, so was previously implicitly licensed as that.
Let’s make that explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The license and copyright are already stated in human-readable form in
these files, so this should be uncontroversial.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The `.flake8` file has a trivial version history, so the copyright is
straightforward from that.
`meson.build` has a more complex history, but the only significant
contributions were from Centricular. From `git log
gio/gdbus-2.0/codegen/meson.build`, the other (following) commits are
too trivial to be copyrightable:
- d10be6102f28e63f5d85c9d8500af28dff2b7ca7
- 30b25a6fd9b48fb94542919288481e0c5f4e77e9
- 95fa229f34f8efdbe44091d1f3f9a87c3139bd52
- 631c3534b784b44578860c1971c4ebd297c40f33
- 00d7568e4f2590af8d7947ca222c9451ada5c2ff
- 9734e4854ebeaee684d566daa97cb518c4488b0e
- 65be80c3edbcf3f10ae63f529a53ba95dddf6186
- 66e4ba806a8e7c4ad933d3b3c063f45f4ccf4504
- a1c78d63ef758df68d01d43d3be8d7c3cb600bea
- a73ca336aa7b0e535338868b296f658a62f0fd77
- 19353017a786e90e00c29890ba6ca2ef88798df4
- b4231844a27352062324a2486f0169315aef5a9c
- 4cb945d780d73319b56cac04f4cbb8f609b8cdc0
- 4ce58df8540f25f823418a1d45ddb07ada52ec22
- e2433308c465df3dd6fd6c34b893ca36da050e39
- 013980d8398b1010c0e3414e5d1f06030fa557d2
Both files were contributed while the `COPYING` file for GLib was
LGPL-2.1-or-later, so both were previously implicitly licensed as that.
Let’s make that explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
The license and copyright are already stated in human-readable form in
these files, so this should be uncontroversial.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1415
Using the same justification as in
https://gitlab.gnome.org/GNOME/dconf/-/merge_requests/81#note_2083220:
it’s hard to get this right, with error handling, in a way which is
understandable to people reading it, and which both bash and shellcheck
will be happy with.
On the assumption that none of the completions generated by any of these
utilities will include ‘problematic’ characters (ones which would cause
word splitting or globbing in bash), just ignore the shellcheck
warnings. Note that I have not actually closely verified that these
utilities can’t return ‘problematic’ characters.
This means we can enable shellcheck, with fatal warnings, for these
scripts, and hence catch future regressions.
If someone wants to improve the handling of globbing/word splitting in
some/all of these array assignments in future, the shellcheck disables
can be removed.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This means that backslashes in the input (which is unlikely, but I guess
possible) won’t affect line splitting. Spotted by shellcheck.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Having them on the same line masks failure of the subcommand generating
the value being assigned. Spotted by shellcheck.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Because completion scripts are not executed directly, they don’t have a
shebang line, so shellcheck can’t be sure which shell syntax to use for
them. Help it out.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than `strdup()`ing strings when passing them into
`_xdg_glob_list_append()`, `strdup()` them *inside* the function
instead.
This avoids a leak in the case that the list entry (tuple of `data` and
`mime_type`) already exists in the list.
This has been upstreamed as
https://gitlab.freedesktop.org/xdg/xdgmime/-/merge_requests/36.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than iterating over the list twice: once to find the resource,
and once to re-find its link and delete it, just use
`g_list_delete_link()` to delete what was found.
This has the lovely side-effect of squashing a false positive from
scan-build, which thought there was a use-after-free of `resource` in
the caller, due to `g_resource_unref()` being called on it here.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
There were a couple of functions in `GDBusConnection` which take a
`user_data` argument, but which then leak it if they error out early.
A true positive spotted by scan-build!
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
There were some error paths where it wasn’t set, returning an
uninitialised value to the caller.
Spotted by scan-build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
It might not actually be needed (I haven’t checked if the default is
correct), but it certainly does no harm and makes things explicit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
