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>
This is a follow up to commit e7e5ddd2a. oss-fuzz found a case where
performance was pathologically bad with a long `stop_chars` string.
Since our inner loop in that case was iterating over `stop_chars` and
comparing each of them to `buffer[i]`, we can use `memchr()` the
opposite way round to in commit e7e5ddd2a to speed that up, using
`buffer[i]` as the needle in a `stop_chars` haystack.
From some brief testing, this doesn’t impact on the performance of a
more normal use case of having a short (<10 bytes long) `stop_chars`. I
was slightly concerned that the function call overhead of calling out to
`memchr()` would have an impact there, but apparently not.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#372994443
This check is necessary for Solaris & illumos, where 32-bit libelf
is incompatible with large-file mode, which meson forces to be enabled,
but 64-bit libelf works fine.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
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 introduces no functional changes, but documents the intent a bit
better in the code where these signal IDs are stored in a struct.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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>
ip_mreqn.imr_ifindex is not used correctly by the XNU kernel, and
causes us to bind to the default interface; so fallback to ip_mreq
and set the iface source address (not SSM).
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/3489
Scanning for stop chars can require looking through a considerable amount
of input data. In the case there is a single stop character, use memchr()
which can be optimized by the compiler to look at word size or greater
amounts of data at a time.
Instead of using singleton initialized the first time when it's needed
we can create the `DBusProxy` object when needed without blocking since
the interface doesn't have any properties nor signals.
The docs recommend using a small number of `keys` when setting data for an
object, the OpenURI portal uses three different `keys` that can easily be replaced
with `g_task_set_task_data()`.
We can’t quite use `access()` for this, like `g_file_test()` does, as
`g_file_query_info()` considers a broken symlink to exist, so we need to
match that by passing `AT_SYMLINK_NOFOLLOW`.
We also use the `AT_EACCESS` flag, which makes the `faccessat()` call
cheaper on Hurd.
Systems without `faccessat()` will continue to use the
`g_file_query_info()`-based implementation of `g_file_query_exists()`.
(Commit message rewritten by Philip Withnall.)
g_file_query_exists looks like a simpler and faster api than
g_file_query_info. This vfunc lets us actually make it faster,
and avoid allocations in this frequently used code path.
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).
Make the generated GDBus-based code use GVariantBuilder with a static
GVariantType to avoid copying the GVariantType on each use.
This is gated behind a GLib 2.83.0 check.
As with the previous commit, this is _always_ defined in `gmacros.h`
and therefore the `#ifndef` will always be 0 even if disabled.
Just use `#if` instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`SOCKS4_CONN_MSG_LEN` failed to account for the length of the final nul
byte in the connect message, which is an addition in SOCKSv4a vs
SOCKSv4.
This means that the buffer for building and transmitting the connect
message could be overflowed if the username and hostname are both
`SOCKS4_MAX_LEN` (255) bytes long.
Proxy configurations are normally statically configured, so the username
is very unlikely to be near its maximum length, and hence this overflow
is unlikely to be triggered in practice.
(Commit message by Philip Withnall, diagnosis and fix by Michael
Catanzaro.)
Fixes: #3461
libinotify-kqueue is a library that implements inotify interface in terms of
kqueue/kevent API available on Mac OS and *BSD systems. The original kqueue
backend seems to be a predecessor version of the code that is currently present
in libinotify-kqueue. Under the hood the library implements a sophisticated
filesystem changes detection algorithm that is derived from the glib backend
code.
Updating the native glib kqueue backend requires substantial work, because code
bases have diverged greatly. Another approach is taken, instead. libinotify-kqueue
can serve as a drop-in replacement for Linux inotify API, thus allowing to
reuse the inotify backend code. The compatibility, however, comes at cost, since
the library has to emulate the inotify descriptor via an unix domain socket.
This means that delivering an event involves copying the data into the kernel
and then pulling it back.
The recent libinotify-kqueue release adds a new mode of operation called "direct".
In this mode the socket pipe is replaced with another kqueue that is used to
deliver events via a kevent(EVFILT_USER) call.
Employing the direct mode requires minor changes to the client code compared
to using plain inotify API, but in return it allows for reusing libinotify's
algorithms without a performance penalty. Luckily, all required changes are
consolidated in one file called inotify-kernel.c
This puts us in the best of possible worlds. On one hand we share a lot of code
with glib inotify backend, which is far more thoroughly tested and widely used.
On the other we support a range of non-Linux systems and consolidate the business
logic in one library. I plan to do the same trick for QFileSystemWatcher which
will give us the same behaviour between Gtk and Qt applications.
The glib test suite passes for both old kqueue backend and new libinotify-kqueue
one. However, the AppStream FileMonitor tests are failing with the old backend,
but pass with the new one, so this is still an observable improvement.
Relevant libinotify-kqueue PR: https://github.com/libinotify-kqueue/libinotify-kqueue/pull/19
This was intended to make it feasible to debug connection failures where
a modern GDBus client connects to a GDBusServer that is missing
glib!2826, but those GDBusServers should be increasingly rare: we have
had the fixed version of GDBusServer for 5 GNOME stable releases
(2 years), long enough to get into stable releases of Debian and Ubuntu
and a service-pack release of SUSE.
This debug message can be very noisy, especially when unit-testing
GLib code (which is frequently done with G_MESSAGES_DEBUG=all) or when
a third-party GLogFunc ignores the log_level parameter and logs all
messages as though they indicated a serious problem. I think it has
served its purpose now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Ideally, we would eventually move to always using the
cross-namespace-friendly authentication handshake and never sending an
initial response with the Unix uid or Windows SID, but that's blocked
on waiting for various LTS OS distributions to become unsupported or
otherwise irrelevant. Make a note of some major LTS distributions that
still have an old version that is missing glib!2826.
In the RHEL/CentOS family, CentOS Stream 10 has a fixed version, so
presumably RHEL 10 will have a fixed version when it is released.
In the Debian family, Debian 12 and Ubuntu 24.04 are stable releases
that contain a fixed version.
In the SUSE family, openSUSE 15.6 contains a fixed version, so
presumably so does SLES 15.6.
Faster-moving distributions like Fedora are not a concern here and
can be ignored: it's always the slow-moving and/or LTS distributions
that are going to be holding back interoperability breaks.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The option defaults to 'auto' which keeps the current selection behavior, but
also allows user to override the choice.
Also make the chosen backend is reported to the code via CPP defines.
This introduces no functional changes, but does squash a false positive
warning from `-Wfloat-conversion`:
```
../gio/gapplication.c:462:15: error: implicit conversion turns floating-point number into integer: 'gdouble' (aka 'double') to '_Bool' [-Werror,-Wfloat-conversion]
if (*(gdouble *) entry->arg_data)
~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
