This could potentially eventually become a public GLib API, but there
doesn’t seem to be a huge need for it right now (e.g. this file contains
the only use of `/proc/self/fd/%d` in GLib), so let’s keep it private
for now and avoid committing to API stability just yet.
This gives time for other platforms to add their platform-specific
implementations for it too, if they need. I’ve added a couple of
pointers to what I *think* the right APIs might be, from my research,
but I have not prototyped those implementations.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When a conversion is finished, the code would return 0 from its write
vfunc. This is disallowed by the API of g_output_stream_write() and
causes g_output_stream_splice() as used by g_converter_convert_bytes()
to turn into an infinite loop.
Instead, raise a G_IO_ERROR_MESSAGE_TOO_LARGE error so that the calling
code can decide how to deal with it.
Testcase included.
Closes#3532
This fixes commit aac56f1618 — I missed
this while reviewing it, but the unit tests were partially changed to
call the new APIs, without being fully changed. This caused the build to
succeed on Linux, but fail on macOS due to using a deprecated API.
Actually, a better approach for the unit tests would be to consistently
call the *old* APIs, as they all immediately call the new APIs. Then we
get coverage of both old and new for free, at the cost of putting
`G_GNUC_BEGIN_IGNORE_DEPRECATIONS` at the top of the test file.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3492
UnixMountEntry: Deprecate g_unix_mount_* API in favor of g_unix_mount_entry_* API for GUnixMountEntry methods
Closes#3492
See merge request GNOME/glib!4337
This issue arises because the g_unix_mount_* naming convention does not match
the GUnixMountEntry instance type, confusing the introspection generator.
To resolve this, we are deprecating the g_unix_mount_* API functions that take
a GUnixMountEntry parameter and introducing equivalent g_unix_mount_entry_*
functions that correctly associate with the GUnixMountEntry instance. This change
ensures that introspection data correctly treats these as instance methods and
that documentation reflects proper ownership of returned data.
(Some minor tweaks by Philip Withnall.)
Fixes: #3492
Commit 760a6f647 rearranged how the lengths are calculated for the test
data and added `escape_data_string()` so they could be printed safely.
Unfortunately there was a miscount in the length of the first test
vector in `test_read_upto()`: there are 31 bytes in the string literal,
plus one nul terminator which is added by the compiler. The quoted
string length was 32 bytes. This should be fine (explicitly including
the nul delimiter), but then `escape_data_string()` adds another byte to
the length because it assumes the nul delimiter has *not* been included
in the count.
Changing the string length from 32 to 31 breaks the tests, as the final
component of the data is then the wrong length, so add an additional
explicit nul byte to the string literal so that it matches the length.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For historical reasons, pid_t & mode_t are defined as long instead
of int for 32-bit processes in the Solaris headers, and even though
they are the same size, gcc issues -Wformat headers if you try to
print them with "%d" and "%u" instead of "%ld" & "%lu".
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The method was correctly returning an error from
`g_data_input_stream_read_line_utf8()` if the line contained invalid
UTF-8, but it wasn’t correctly setting the returned line length to 0.
This could have caused problems if callers were basing subsequent logic
on the length and not the return value nullness or `GError`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372819437
This makes no functional changes, but does tidy the code up a bit and
means `g_steal_handle_id()` gets a bit more testing.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For the reasons given in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4176#note_2233317,
it’s best to not rely on subprocesses when writing tests. Spawning a
subprocess can go wrong, getting feedback and assertion data from a
subprocess is a pain, and making sure the subprocess is killed properly
at the end of the test is hard to get right.
For tests where we are trying to mock a D-Bus service, it’s much more
reliable to run that service in-process (either in the main thread or in
a separate thread).
So, do that for the `fake-document-portal` former subprocess in the
`dbus-appinfo` test: move it to a worker thread.
This speeds the test up, simplifies the build slightly, and should make
the test run more reliable.
In particular, it provides a pattern for future `fake-*-portal` tests to
be built off. This is particularly useful for more complex portals,
where data needs to be relayed back from the mock portal service to the
unit test to check that the code under test has behaved properly. That’s
a pain to do from a subprocess.
Delete the `org.freedesktop.portal.Documents.service` file because we no
longer need to rely on D-Bus service activation within the test, as
we’re setting up the mock service thread explicitly now.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is better than using `g_getenv ("DBUS_SESSION_BUS_ADDRESS")` as it
will fail more explicitly if the mock bus somehow isn’t running.
This will be used in an upcoming commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
All uses of g_variant_builder_init() in gio are safe to translate to the
new g_variant_builder_init_static() alternative as the type will outlive
the call to g_variant_builder_end() (or is already static in nature).
Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the
glib Meson policy says we can update. Update the minimum only as far as
1.4.0 because we don't yet have a need for 1.5.0.
This allows us to:
- Use file.full_path() to avoid deprecation warnings on str.format(file).
- Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC.
Update all the CI builds to use the latest 1.4.x patch release, 1.4.2.
The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be
broken for now.
Similarly, the macOS build will not work unless `-Dc_std=gnu99` is
specified at configure time, due to
https://github.com/mesonbuild/meson/issues/13639.
This was one of the code paths not currently covered by unit tests, so
let’s add a test for it.
This tests what happens when a structurally valid GResource file, but
with a corrupt entry for a compressed file, is loaded.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The test in `unix-mounts` to see whether `g_unix_mounts_get_from_file()`
can parse an example file was working fine when GLib is built with
libmount, but not when built without it (and hence typically using
`getmntent()`).
This is because libmount supports mountinfo files (like
`/proc/self/mountinfo`), but `getmntent()` only supports mount files
(like `/proc/mounts`). The test was written only with the former.
So, change the test to use mount files when GLib is built without
libmount support.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3456
These tests are expected to cause a thread to deadlock. That seems to be
fine with glibc on Linux, but the glibc version on FreeBSD can detect
the deadlock, and aborts the whole test process with:
```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_mutex_lock': Resource deadlock avoided. Aborting.
```
This is fair enough.
To avoid this causing the test suite to fail, run those two tests in
subprocesses. This also means we’re not carrying a deadlocked thread
around for the rest of the test suite.
Improves on commit 62192925b6.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
While GLib doesn’t parse these files, it does provide API to access the
fields from them, and does implement some logic based on options fields
in them. It would be nice to be able to test that, and get coverage of
the methods for `GUnixMountPoint` and `GUnixMountEntry`.
You may not always know which schemes are available.
The library should not bail out, but only show
an informal message. It's the responsibility of
the application to deal with invalid URI schemes.
The test brings a Finder window to the front. It's not ideal,
but I have no better idea at the moment. It would be cool if we
can make the test case register itself as handler for a particular
uri scheme, but I have no idea how to do that.
