I made a mistake when last updating the documentation in 94a99ae9. I
wrote that, with TLS 1.3, this would perform a rekey instead of a
rehandshake. In fact, that's only true for client connections. For
server connections, it's a no-op.
I was a bit nervous about how to document the behavior anyway, because
we really don't know what behavior will be reasonable with non-GnuTLS
crypto backends. This behavior is reasonable for the GnuTLS backend, but
might not necessarily make sense for OpenSSL. Ideally, we would
discourage API users from doing things which could have unexpected
effects, so instead of documenting what the GnuTLS backend does, I think
it'd be better to document that this is "undefined but not dangerous,"
since of course we want to make sure that existing code that doesn't
know about TLS 1.3 is not broken.
Previously, g_log_writer_is_journald() would cache the result for the
first (non-negative) FD it was called on, and return that result for
all future (non-negative) FDs. While unlikely, it's possible that
applications might call this function on something other than
fileno(stderr).
Move the memoization into g_log_writer_default(), which always passes
fileno(stderr).
Fixes#1589.
Currently, GDBusProxy:g-name-owner only notifies changes to the unique
name owner of the remote object in case the proxy was constructed for a
well-known name.
That sounds like an artificial restriction, and it's convenient to
connect to notify::g-name-owner if a proxy instance has already been
created for an unique name, instead of additionally using
g_bus_watch_name() to track the owner.
To fix this, always connect to NameOwnerChanged after the proxy is
initialized, instead of only doing so when the proxy was constructed for
a well-known name.
https://bugzilla.gnome.org/show_bug.cgi?id=791316https://gitlab.gnome.org/GNOME/glib/issues/1310
The length of the stolen data from a memory output stream is given by
get_data_size() — get_size() can be larger, and hence cause unnecessary
overallocation.
Closures use a 16-bit atomic reference count, which is really slow
on certain ARM64 CPUs such as the Cortex-A57 (glib#1316). This is
non-trivial to solve, since the public struct field cannot be enlarged
to 32-bit while preserving ABI, and 16-bit atomic operations would be new
(and rather niche) API.
Until this can be solved properly (hopefully in GLib 2.59.x), cut down
the number of signal emission cycles and bump up the timeout in the
Meson build system, so that builds won't time out. We can't just take
another zero off the number of signal emission cycles, as was done in the
original version of this patch in Debian, because if we do that it can
result in test failures when the main thread starves the other threads.
ARM64 CPUs are backwards-compatible with 32-bit ARM, and the same
slowdown can be seen when building and testing 32-bit code on these
CPUs, so check for both 32- and 64-bit ARM.
Bug-Debian: https://bugs.debian.org/880883
Co-authored-by: Iain Lane <laney@debian.org>
Signed-off-by: Simon McVittie <smcv@debian.org>
Rather than duplicating the alignment checks when constructing a new
GVariant, re-use the alignment checks from GVariantSerialised. This
ensures that the same checks are done everywhere in the GVariant code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1342
Otherwise the GVariant would later fail internal alignment checks,
aborting the program.
If unaligned data is provided to (for example)
g_variant_new_from_data(), it will copy the data into a new aligned
allocation. This is slow, but better than crashing. If callers want
better performance, they should provide aligned data in their call, and
it will not be copied or reallocated.
Includes a unit test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1342
This was causing a crash, because we were first removing an item, freeing
both the instance itself and the key, and then trying to reuse those.
So, in this case, instead of reassigning an item, we can just return TRUE
as we have already the item at the right place, while it's not needed to
update the modified timestamp, since no modification happened in reality.
Fixes#1588
Synchronize access to random number generator `test_run_rand` with
a lock to ensure that `g_test_rand_*` family of functions is
thread-safe.
The reseeding taking place between test case runs is intentionally left
unsynchronized. It is an error to continue using random number generator
after test case has already finished running. Lack of synchronization
here will make such erroneous use readily apparent with thread
sanitizer.
This test isn't inherently slow, but it produces so much output that
it can take a minute or more on hardware with weak I/O performance.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is enough for most Debian buildds, including embedded devices
like mips and powerpcspe. It is not enough for hppa (PA-RISC), but that
architecture is so uniquely slow that it might make more sense to
special-case it downstream.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This reverts commits:
• 9ddcc79502
• ae02adc3c3
g_date_time_format() supports a few non-standard format placeholders:
• %:z
• %::z
• %:::z
These are all gnulib strtime() extensions, and hence are not recognised
by the compiler when the function is annotated with G_GNUC_STRFTIME.
However, this wasn’t noticed when we originally merged this change
because the errors were disabled in the tests which covered those
placeholders.
This does not work, since g_date_time_format() supports
non-standard extensions such as %:::z, and this has
broken several consumers which use format errors, such
as ostree.
