This warning warns on widening casts from integer to pointer type,
because those casts can be problematic for porting to new pointer
sizes. The code in question didn't do any bad things here so an
intermediate cast to size_t was added to silence the warning
This test was exploiting unspecified behavior w.r.t. the address of string
literals, It expected them to be pooled (the same literal has the same
address, at least within a TU), but MSVC does not pool by default,
leading to a failure.
gspawn: Implement fd remapping for posix_spawn codepath, and fix file descriptor conflation issues
Closes#2503 and #2506
See merge request GNOME/glib!1968
This tests for #2503. It's fragile, but there is no non-fragile way to
test this. If the test breaks in the future, it will pass without
successfully testing the bug, not fail spuriously, so I think this is
OK.
Although unlikely, these functions can fail, e.g. if we run out of file
descriptors. Check for errors to improve robustness. This is especially
important now that I changed our use of dupfd_cloexec() to avoid
returning fds smaller than the largest fd in target_fds. An application
that attempts to remap to the highest-allowed fd value deserves at least
some sort of attempt at error reporting, not silent failure.
We should run test_pass_fd twice, once using gspawn's fork/exec codepath
and once attempting to use its posix_spawn() codepath. There's no
guarantee we'll actually get the posix_spawn() codepath, but it works
for now on Linux.
For good measure, run it a third time with no flags at all.
This causes the test to fail if I separately break the fd remapping
implementation. Without this, we fail to test fd remapping on the
posix_spawn() codepath.
We currently dup all source fds to avoid possible conflation with the
target fds, but fail to consider that the result of a dup might itself
conflict with one of the target fds. Solve this the easy way by duping
all source_fds to values that are greater than the largest fd in
target_fds.
Fixes#2503
In case child_err_report_fd conflicts with one of the target_fds, the
code here is careful to dup child_err_report_fd in order to avoid
conflating the two. It was a good idea, but evidently was not tested,
because the newly-created fd is not created with CLOEXEC set. This means
it stays open in the child process, causing the parent to hang forever
waiting to read from the other end of the pipe. Oops!
The fix is simple: just set CLOEXEC. This removes our only usage of the
safe_dup() function, so it can be dropped.
Fixes#2506
Specs say that on Unix id should be desktop file id from the xdg menu
specification, however, currently code just uses basename of .desktop file.
Fix that by finding the .desktop file in all the desktop_file_dirs and use
basename only as a fallback.
See https://specifications.freedesktop.org/menu-spec/latest/go01.html#term-desktop-file-id
and https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id
"To determine the ID of a desktop file, make its full path relative to the
$XDG_DATA_DIRS component in which the desktop file is installed, remove the
"applications/" prefix, and turn '/' into '-'."
Also, add unit test that verifies Desktop Id is being correctly set
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Make it so USE_XLOCALE is set whenever newlocale() and uselocale() are
available. This way, we can still use the _g_snprintf() path for some
functions, and also use the *_l functions when they are available.
newlocale(3) are uselocale(3) part of POSIX 2008, while the *_l
functions being used are nonstandard glibc extensions. Gating all the
locale functionality behind them meant we were using fallbacks on non
glibc platforms unnecessarily.
Further changes to this code could add fallback for the non _l suffixed
number parsing functions, but that might be unnecessary complexity.
Fixes#2553
Might make the API documentation a little easier to find from the GitLab
landing page for GLib.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If a path starts with more than two slashes, the `start` value was
previously incorrect:
1. As per the `g_path_skip_root()` call, `start` was set to point to
after the final initial slash. For a path with three initial
slashes, this is the character after the third slash.
2. The canonicalisation loop to find the first dir separator sets
`output` to point to the character after the first slash (and it
overwrites the first slash to be `G_DIR_SEPARATOR`).
3. At this point, with a string `///usr`, `output` points to the second
`/`; and `start` points to the `u`. This is incorrect, as `start`
should point to the starting character for output, as per the
original call to `g_path_skip_root()`.
4. For paths which subsequently include a `..`, this results in the
`output > start` check in the `..` loop below not skipping all the
characters of a preceding path component, which is then caught by
the `G_IS_DIR_SEPARATOR (output[-1])` assertion.
Fix this by resetting `start` to `output` after finding the final slash
to keep in the output, but before starting the main parsing loop.
Relatedly, split `start` into two variables: `after_root` and
`output_start`, since the variable actually has two roles in the two
parts of the function.
Includes a test.
This commit is heavily based on suggestions by Sebastian Wilhemi and
Sebastian Dröge.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
oss-fuzz#41563
The tests were previously only checking the macro forms. The function
forms should behave identically, but since it’s easy enough to get
coverage of them, we might as well.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This decreases the overall test time from 0.17s to 0.12s for me, and
will help further in the following commit where I’m going to repeat some
of these calculations again for further comparisons.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
