On non-systemd Gentoo systems the chosen timezone is expressed in
/etc/timezone and /etc/localtime may be a copy of the timezone
file instead of symlink. Add this path to the fallback test to
not regress dates into UTC.
opendir and closedir are not async-signal-safe, these may call malloc
under the hood and cause a deadlock in a multi-threaded program.
This only affected Linux when /proc is mounted, other systems use a
slower path that iterates through all potential file descriptors.
Fixes a long-standing problem (since GLib 2.14.2).
Closes#945 and #1014
There are languages where a name of one month is a substring of another.
Instead of stopping search on the first match use the month that
constitutes the longest match.
(Backport to glib-2-58: Fix minor merge conflict.)
Fixes#1343.
test_c_args is defined in the root meson.build with unfiltered list of
compiler flags, then redefined in gio/tests/meson.build after the
subdir() call. Move it before.
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.
(cherry picked from commit 68878ab50b2a25f2ec9b3caf0d49a83bc489914a)
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
Previously, the markup parsing test would load a given markup file and
try to parse it several ways. It would return as soon as one of the
attempts failed — meaning that bugs only seen with non-nul-terminated,
or differently chunked, parse runs could never be caught.
Rework the tests so that all markup files are tested all ways, and we
assert that all ways of parsing them give the same result.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously, the element name validation only happened if a start_element
callback was specified on the context. Element name validation should be
unconditional.
This was causing test-5.gmarkup to fail when run against the improved
tests in the following commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When extracting a UTF-8 character to put in an error message on parse
failure, pass the remaining buffer length to utf8_str() to avoid it
running off the end of the input buffer. It previously assumed that the
buffer was nul-terminated, which was the case in all the tests until
now.
A following commit will add test coverage for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using GMarkup to parse a string, the string can be provided with an
explicit length specified, or with no length and a nul terminator
instead. Run all the GMarkup tests both ways, to catch problems with
length checks, or with nul terminator checks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This doesn’t trigger any new failures, but is distinct from other tests
we have, so would be good to retain.
Related to commit cec71705406f0b2790422f0c1aa0ff3b4b464b1b.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These were callers which explicitly specified the string length to
g_utf8_validate(), when it couldn’t be negative, and hence should be
able to unconditionally benefit from the increased string handling
length.
At least one call site would have previously silently changed behaviour
if called with strings longer than G_MAXSSIZE in length.
Another call site was passing strlen(string) to g_utf8_validate(), which
seems pointless: just pass -1 instead, and let g_utf8_validate()
calculate the string length. Its behaviour on embedded nul bytes
wouldn’t change, as strlen() stops at the first one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a variant of g_utf8_validate() which requires the length to be
specified, thereby allowing string lengths up to G_MAXSIZE rather than
just G_MAXSSIZE.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This introduces no real functional changes (except when compiling with
G_DISABLE_ASSERT, in which case it fixes the test). Mostly just a code
cleanup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code was checking whether the signature provided by the blob was a
valid D-Bus signature — but that’s a superset of a valid GVariant type
string, since a D-Bus signature is zero or more complete types. A
GVariant type string is exactly one complete type.
This meant that a D-Bus message with a header field containing a variant
with an empty type signature (for example) could cause a critical
warning in the code parsing it.
Fix that by checking whether the string is a valid type string too.
Unit test included.
oss-fuzz#9810
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Parsing a D-Bus message with the signature field in the message header
of type other than ‘g’ (GVariant type signature) would cause a critical
warning. Instead, we should return a runtime error.
Includes a test.
oss-fuzz#9825
Signed-off-by: Philip Withnall <withnall@endlessm.com>
