Nobody’s going to keep it up to date if it’s floating about in an
unrelated place, not next to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Nobody’s going to keep it up to date if it’s floating about in an
unrelated place, not next to the code.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Just like we have `g_steal_pointer()` and `g_clear_pointer()`, it would
be useful to have a ‘steal’ version of `g_clear_handle_id()`.
Particularly in situations where a clear function can’t be represented
as a `GClearHandleFunc`, such as
`g_dbus_connection_signal_unsubscribe()` (there’s no way of passing the
`GDBusConnection` to it) — or in situations where a handle ID isn’t
being released, but is being passed from one struct to another or from a
local scope to a struct or vice-versa.
Includes unit tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
And to not assume that every main context iteration will provide
progress on the sources that the test is interested in. It’s possible
that other sources may be attached to the `GMainContext` which get
dispatched instead of the pipe sources on an iteration.
I don’t know if this will fix#3483, but it will certainly make this
test a little tidier. It doesn’t affect test run time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3483
Otherwise `scan-build` thinks it’s possible for the `GBytes` to be
double-freed, which would indeed happen if `try_steal_and_unref()` were
to return `NULL` on this branch.
It’s not actually possible for it to return `NULL` here though, as if
`bytes->data` were `NULL`, the function would have already returned
higher up.
Fixes this `scan-build` failure:
https://gitlab.gnome.org/GNOME/glib/-/jobs/4359929
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This fixes commit 9eb9df2396, which I really should have noticed at the
time would cause a load of unused variables to be declared if compiled
with `G_DISABLE_ASSERT`. That’s what the original `#ifdef`s were to
protect against.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
We want to keep the suffix aligned to 8 bytes on 32-bit too. This makes
sure we do that in a way that is portable across our supported compilers.
Fixes: #3486
This reverts commit 16819a4024.
The failure this was added for is intermittent and has been going on a
long time; it’s not a new failure caused by msys2 dependency/packaging
changes, so the policy in .gitlab-ci.yml doesn’t apply.
It would be great if someone fixed#3042, but un-gating GLib from msys2
testing is not the right tradeoff for it.
See: #3042
We want to build GLib against a matched version of
gobject-introspection, and this version will probably be bumped quite
often as the two are developed in tandem.
However, if the CI system provides a newer version, we should probably
use that, otherwise we’re essentially downgrading part of the OS on the
CI system, and that probably will result in issues. In particular,
gobject-introspection <1.82 has a bug on MSYS2 which means it doesn’t
build (see issue #3464).
So, build gobject-introspection manually if the CI system version is too
old, otherwise use the system version. Do this programmatically so we
don’t have to repeatedly add and remove the gobject-introspection build
commands from the CI configuration as versions are bumped.
Fixes: #3464
This option was renamed to `branch_coverage` in more recent versions of
lcov. This might explain why branch coverage is not being collected by
CI at the moment.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Now that the implementation of it is significantly more complex,
involving pointer arithmetic, it should probably be fuzzed. It’s not an
API which is obviously used to handle untrusted input, but some users of
GLib might do so.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Current implementation replaces find in string with replace
one-at-a-time and replacement is done in O(n^2) time. The new
implementation is O(n). Memory allocation is done once instead of
incrementally.
In the old implementation, every replacement will move the whole
rest of the string from the current position to make space for
the replace string and then insert the replace string.
In the new implementation, when the replace string is shorter or equal
to the find string, it will move the characters in-place and requires no
additional memory. When the replace string is longer, find the required
size needed for the new string and preallocate a new string to copy the
original string to with its replacements. When the replace string is an
empty string use the old implementation to handle the special case.
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>
Previously, all GVariants would allocate a GBytes for the buffered
contents. This presents a challenge for small GVariant type created
during the building process of GVariantBuilder as that results in an
allocation for the GVariant, GBytes, and the byte buffer.
Recent changes for GBytes may reduce those 3 allocations to 2, but even
that is quite substantial overhead for a 32-bit integer.
This changeset switches GVariant to use g_new/g_free allocators instead
of g_slice_new/free. When benchmarked alone, this presented no
measurable difference in overhead with the standard glibc allocator.
With that change in place, allocations may then become variable in size
to contain small allocations at the end of the GVariant reducing things
to a single allocation (plus the GVariantTypeInfo reference).
The size of GVariant is already 1 cacheline @ 64-bytes on x86_64. This
uses that to guarantee our alignment of data maintains the 8-bytes
guarantee of GVariant, and also extends it to match malloc().
On 32-bit systems, we are similarly aligned but reduce the amount we
will inline to 32 bytes so we have a total of 1 cacheline.
This is all asserted at compile-time to enforce the guarantee.
In the end, this changeset reduces the wallclock time of building many
GVariant in a loop using GVariantBuilder by 10% beyond the 10% already
gained through GBytes doing the same thing.
Now that the CI runner has Meson 1.4, we can revert commit
eda5bb386b and re-enable fatal warnings.
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.
This adds another form of stack building which allows avoiding the rather
expensive GVariantType malloc/memcpy/free. In a tight loop this reduced
wallclock time by about 4-5% for cases where you do not need to further
open using g_variant_builder_open() which still require a copy at this
time.
New API is provided instead of modifying g_variant_type_init() because
previously it was possible (though misguided) to use g_variant_type_init()
which a dynamically allocated GVariantType which could be freed before
g_variant_builder_end() or g_variant_builder_clear() was called.
# Conflicts:
# glib/gvariant.c
When trying to locate a GVariantTypeInfo from the cache we were copying
the string so that we can use g_str_hash, as that requires a \0 terminated
string.
However, we have hash and equal functions which can be used without the
extra copy. Additionally, these were moved to headers in previous commits
so they can be used without having to re-check GVariantType we already
know to be valid.
Use the [provide] section to override the binary name, and track the
main development branch, like GTK does, so we get warnings and a
consistent output.
