(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>
This repurposes the existing skip-all test as "combining", since it
is no longer entirely about runs where every test-case was skipped.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If a test is marked with g_test_incomplete(), then it is expected to
fail, so when it fails the test executable should still exit 0
(or possibly 77, if all tests are either skipped or incomplete).
Signed-off-by: Simon McVittie <smcv@collabora.com>
In the test for the unit testing framework, we might as well have
exemplary behaviour. Leave behind a single call to g_assert (TRUE)
just to prove that it still works.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The TAP specification says that failing tests that are currently
expected to fail (like Automake's XFAIL) are to be reported as
"not ok", with that failure ignored as a result of the TODO
directive, with this example:
not ok 3 - infinite loop # TODO halting problem unsolved
A test reported as "ok # TODO" indicates that something that is
expected to fail has unexpectedly succeeded, similar to Automake's
XPASS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Assigning the gpointer return value from g_atomic_pointer_get() to a
gsize variable was not making -Wbad-function-cast happy. Assign to an
intermediate gpointer variable and then cast that instead.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1475
g_test_skip() is appropriate for tests that can't run due to missing
functionality on the host system, whereas g_test_incomplete() is
for expected-to-fail tests for unimplemented functionality in the
code under test.
See also https://bugzilla.gnome.org/show_bug.cgi?id=793635 and
commit 5459b345.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Testing that an interned string is released once its last reference is
dropped is not possible without a hook into the interning machinery;
just checking that the returned pointer for the same string is going to
be different after the last release() is not guaranteed to work, as the
systema allocator is perfectly within its rights to recycle pointers, as
long as they are unique while valid.
Closes#1467
When checking that the timezone code falls back to UTC if a zone is
unknown, don’t use ‘PST’, because that can actually exist on some
systems.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1433
See previous commit; same reasoning behind the commit, except that these
sources weren’t (yet) causing `make distcheck` to fail.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of messing around with EXTRA_*_SOURCES and manually handling .lo
files, why not just add gwin32.c to the GLib sources conditionally?
This will hopefully fix `make distcheck` failing due to gwin32.Plo not
being generated in the sub-builddir≠srcdir stage, due to depcomp
inexplicably not generating it. (Note that it is correctly generated in
non-distcheck builds.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The parser state machine for bookmark files did not handle unexpected
nesting of elements, such as a <bookmark> element inside a <title>
element — it would print a critical warning rather than returning a
GError.
Fix that, and add various unit tests for it. The set of tests includes
various other general markup tests as provided by Jussi Judin.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1035
That should format these character classes correctly in the
documentation, and prevent them being interpreted by gtk-doc as (broken)
Markdown hyperlinks.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fixes a gtk-doc complaint about the argument name not matching
what’s used in the gtk-doc comment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If something which looks like a closing tag is left unfinished, but
isn’t paired to an opening tag in the document, the error handling code
would do a null pointer dereference. Avoid that, at the cost of
introducing a new translatable error message.
Includes a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1461
When formatting the error messages for markup parsing errors, the parser
was unconditionally reading a UTF-8 character from the input buffer —
but the buffer might end with a partial code sequence, resulting in
reading off the end of the buffer by up to three bytes.
Fix this and add a test case, courtesy of pdknsk.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1462
We should bail when we detect that adding a number of items to an array
would cause it to overflow. Since we can't change to using gsize for ABI
reasons we should protect the integrity of the process even if that means
crashing.
These tests will work if the glibc translations are up to date, or if
the GLib translations are installed and up to date; but not if neither
are in place.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
https://gitlab.gnome.org/GNOME/glib/issues/1447
This has the same rationale as the corresponding change to the gdatetime
tests; commit 9cadb90b35af5820bc1ee9f527fcf92a2f145cb3.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
https://gitlab.gnome.org/GNOME/glib/issues/1447
