All of the indications in the surrounding code are that `node` should
never be `NULL`, but the error handling for it did actually allow it to
be `NULL` iff its `parent` was also `NULL`.
That made scan-build (kind of legitimately) warn about `NULL` pointer
dereferences of `node`.
Avoid that by unambiguously using an assertion to prevent `NULL` nodes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
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
scan-build thinks that the `atypes` array is leaked, but it’s not.
Ownership is transferred into the `ffi_cif` structure, and it’s
eventually freed in `gi_callable_info_destroy_closure()`.
Try and help the static analysis by adding an explicit ownership
transfer annotation. It probably won’t help.
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
This enables `NULL` pointer dereference checking in the compiler. This
isn’t as good as static analysis, but it should hopefully catch some
simple errors without too high a false positive rate.
If the false positive rate is too high to be useful, we can always
disable it again.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
Eventually, we do want to include them in static analysis (their code is
run in the same process as GLib, after all). But for now, that’s too
much work to get started.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
It’s not highlighting severe bugs for us, and currently generates 132
out of 172 of the scan-build reports, so let’s disable it for now.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
They cause too much noise at the moment. I want to make scan-build
messages fatal, and with 66 of 238 reports coming from the tests,
that’s not currently feasible.
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>
This reverts commit 280c8d41fb.
It breaks the unit tests on macOS (see #3314) and no fix has been
forthcoming.
The alternate stack changes can be resubmitted once they include a
working unit test on macOS, as evidently its treatment of alternate
stacks differs from that on Linux, and hence needs testing.
Helps: #3314
Just like we already do in `GSocket`.
This is necessary when using `g_subprocess_communicate()` with a
subprocess which calls `close()` on its stdin FD at some point. `cat`
does this just before exiting, for example.
This causes a `write()` to the stdin pipe in the parent process to fail
with `EPIPE` and `SIGPIPE`. The condition is not detectable in advance,
because the `close()` call could happen after the `GMainContext` has
dispatched a `g_subprocess_communicate()` callback.
If it weren’t for the `SIGPIPE`,`g_subprocess_communicate()` would be
able to handle the `EPIPE` just fine. `SIGPIPE` seems like a default
error handling path which was useful in 1980 for writing pipe-heavy
command line apps, but which is more of a broken stair for writing
larger modern apps which have more than one data flow path.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3310
With the shell in nounset mode, an error is emitted on referencing
`schemadir` as it is not initialized in all code paths.
Initialize to an empty string to fix.
Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
