glibc string.h declares memcpy() with attribute(nonnull(1,2)), causing
calls with NULL arguments to be treated as undefined behaviour.
This is consistent with ISO C99 and C11, which state that passing 0
to string functions as an array length does not remove the requirement
that the pointer to the array is a valid pointer.
gcc -fsanitize=undefined catches this while running OSTree's test suite.
Similarly, running the GLib test suite reports similar issues for
qsort(), memmove(), memcmp().
(This is a partial cherry-pick of commit e5ed410c8c from GLib.)
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=775510
Reviewed-by: Colin Walters
GVDB is essentially part of GLib, so should have the same maintainer
list.
At least this way, it’s not just maintained by one absentee maintainer.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some of the test vectors don’t specify a timezone, so the local one is
used; the comparisons to the expected results (which are in UTC) then
fail.
See discussion in
https://gitlab.gnome.org/GNOME/glib/merge_requests/225.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Part of runMkenumsWithHeader() was duplicated in test_reproducible(),
and would otherwise need to be duplicated again in upcoming tests. Many
places duplicated decoding stdout/stderr and checking the exit code.
Introduce a named tuple for the returned fields; and factor out writing
a template file to pass with --template.
When calculating the value of a timezone offset, ensure that any offsets
done with negative numbers are done in a signed integer.
oss-fuzz#9815
Signed-off-by: Philip Withnall <withnall@endlessm.com>
token_stream_prepare() was over-reading at the start of bytestring
literals (`b'blah'`).
Add tests for that, and for some other situations regarding bytestring
literal parsing, in order to try and get full branch coverage of that
bit of code.
oss-fuzz#9805
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The token_stream_peek() functions were not doing any bounds checking, so
could potentially read 1 byte off the end of the input blob. This was
never noticed, since the input stream is almost always a nul-terminated
string. However, g_variant_parse() does allow non-nul-terminated strings
to be used with a @limit parameter, and the bugs become apparent under
valgrind if that parameter is used.
This includes modifications to the test cases to cover the
non-nul-terminated case.
Spotted by ossfuzz.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
While mountpoints are *not* symlinks, strictly speaking,
they works in a similar enough way, so consider them to be
symlinks for the purpose of querying local file info.
On Windows st_ctime field is the file creation time.
POSIX mandates that field to be the file state change time.
Naturally, glib code interpreted st_ctime as POSIX suggested,
and the result was bad.
Fix this by introducing special W32-only logic for setting
attributes from st_ctime field.
Fixes issue #1452.
(Tweaked by Philip Withnall <withnall@endlessm.com> to fix some minor
leaks, code formatting, and add a test comment.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
These come from looking at the code coverage data. We should now have
full branch coverage of the ISO 8601 parser.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It never worked; we’ve always parsed the year with strtoul() (unsigned).
While negative years are supported by the ISO 8601 standard, they can
only be used by mutual agreement of the two parties interchanging data.
Moreover, they are not supported by GTimeVal, which is what we’re
filling with the results.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code was previously doing a few bits of arithmetic without checking
whether they would overflow, and hence not validating the date/time it
was parsing very strictly.
The parser is now not 100% strict, but should avoid any arithmetic
overflows which would cause an invalid result to be returned even though
g_time_val_from_iso8601() had returned TRUE.
oss-fuzz#9673
Signed-off-by: Philip Withnall <withnall@endlessm.com>
