I wish people would stop moving their documentation around without
adding redirects. This is not how the internet is supposed to work.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
These two data structures are allocated once and live for the lifetime
of the process, and are leaked on exit. That’s fine, and intentional.
Add `g_ignore_leak()` to them to make that a bit clearer, and
communicate the intent to asan.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3472
The goal of this change is to avoid re-parsing `GVariantTypeInfo` on
every creation or parsing of a `GVariant` byte-buffer. Parsing presents
a non-trivial amount of overhead which can typically be elided.
It was discovered that many applications and tooling are re-generating
this information upon receiving a D-Bus message as they tend to process
messages serially, thus dropping the last reference count.
Previously, when the last reference count for a `GVariantTypeInfo` was
dropped we would finalize the parsed type information.
This change keeps `GVariantTypeInfo` alive in a Garbage Collected array.
The array is collected upon reaching a 32 entries. The number 32 was
chosen because it is larger than what I've seen active on various D-Bus
based applications-or-daemons.
Take a simple test case of using `GVariantBuilder` in a loop with a
debugoptimized build of GLib. A reduction in wallclock time can be
observed in the 35% to more than 70% based on the complexity of the
GVariant being created.
For cases like ibus-daemon, it was previously parsing `GVariantTypeInfo`
up to dozens of times per key-press/release cycle.
Closes: #3472
While reading a single byte or uint16 from an input stream is fairly
simple and uncontroversial, the code to read a line or read up to any of
a set of stop characters is not so trivial. People may be using
`GDataInputStream` to parse untrusted input like this, so we should
probably test that it’s robust against a variety of input conditions.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
...in the main tests that we expect to pass.
Due to an upstream issue in PCRE2-10.44, disable running the PCRE2 tests for
now, until the next release (or so) of PCRE2, as the issue has already been
resolved in upstream PCRE2 but has not made it to the PCRE2 release that we use
for our subprojects.
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
...and add ability to select target platform for calling vcvarsall.bat,
so that we can accomodate 32-bit builds and possibly ARM64 builds in the
CI if we need to.
Limit the input size. With a short @find, and a long `init` and `replace`
it’s quite possible to hit OOM. We’re not interested in testing that — it’s
up to the caller of `g_string_replace()` to handle that. 1KB on each of the
inputs should be plenty to find any string parsing or pointer arithmetic
bugs in `g_string_replace()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
oss-fuzz#371233785
This patch fixes a build error when compiling with GCC cross compiler for Windows on ARM64.
See issue #3490 for details.
Signed-off-by: Carlo Bramini carlo_bramini@users.sourceforge.netFixes: #3490Closes#3490
This arm of the condition is always true, because 0x00 has been checked
in the previous branch.
This is not going to improve performance, but does mean we now have full
branch coverage of the code via our unit tests, which gives some
assurance that it’s all good.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3481
The move to c-utf8 for validation has exposed a few new branches where
our existing (fairly comprehensive) UTF-8 validation test suite didn’t
check things.
Add unit tests for those branches, so we keep code coverage.
I’ve validated (with an independent UTF-8 decoder) that the test vectors
are correctly marked as valid/invalid in the test data (so the tests
aren’t just blindly coded to match the behaviour of the new validator
code).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3481
It turns out it’s not actually been explicitly tested before, even
though it has full code coverage through being called by other code
which is tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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.
