GitLab

While the XML specification doesn’t prescribe a limit, no reasonable bit
of XML is going to have more than 1000 attributes in a single XML
element.

Adding a limit reduces the changes of a runaway allocation loop caused
by dodgy input.

oss-fuzz#12960
Signed-off-by: Philip Withnall <withnall@endlessm.com>

These squash various warnings from `scan-build`. None of them are
legitimate bugs, but some of them do improve code readability a bit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1767

In file included from glib/glibconfig.h:9,
                 from ../glib.git/glib/gtypes.h:32,
                 from ../glib.git/glib/gquark.h:32,
                 from ../glib.git/glib/gerror.h:28,
                 from ../glib.git/glib/gmarkup.h:28,
                 from ../glib.git/glib/gmarkup.c:28:
../glib.git/glib/gmarkup.c: In function ‘unescape_gstring_inplace’:
../glib.git/glib/gmarkup.c:789:30: error: comparison of integer expressions of different signedness: ‘long int’ and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
   g_assert (to - string->str <= string->len);
                              ^~
../glib.git/glib/gmacros.h:455:25: note: in definition of macro ‘G_LIKELY’
 #define G_LIKELY(expr) (expr)
                         ^~~~
../glib.git/glib/gmarkup.c:789:3: note: in expansion of macro ‘g_assert’
   g_assert (to - string->str <= string->len);
   ^~~~~~~~
../glib.git/glib/gmarkup.c:790:24: error: comparison of integer expressions of different signedness: ‘long int’ and ‘gsize’ {aka ‘long unsigned int’} [-Werror=sign-compare]
   if (to - string->str != string->len)
                        ^~
../glib.git/glib/gmarkup.c: In function ‘g_markup_parse_boolean’:
../glib.git/glib/gmarkup.c:2634:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
   for (i = 0; i < G_N_ELEMENTS (falses); i++)
                 ^
../glib.git/glib/gmarkup.c:2645:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Werror=sign-compare]
   for (i = 0; i < G_N_ELEMENTS (trues); i++)
                 ^

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>

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>

GMarkup is not to be used for untrusted input. It’s always been designed
for parsing application-provided data files, not random stuff sent to
you by an attacker.
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

This reverts commit 2d56c49b.

All glib/*.{c,h} files have been processed, as well as gtester-report.

12 of those files are not licensed under LGPL:

	gbsearcharray.h
	gconstructor.h
	glibintl.h
	gmirroringtable.h
	gscripttable.h
	gtranslit-data.h
	gunibreak.h
	gunichartables.h
	gunicomp.h
	gunidecomp.h
	valgrind.h
	win_iconv.c

Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.

Sub-directories inside glib/:

	deprecated/: processed in a previous commit
	glib-mirroring-tab/: already LGPLv2.1+
	gnulib/: not modified, the code is copied from gnulib
	libcharset/: a copy
	pcre/: a copy
	tests/: processed in a previous commit

https://bugzilla.gnome.org/show_bug.cgi?id=776504

g_utf8_make_valid was turned into a public API this cycle. However
now that it is public we should make the API more generic, allowing
the caller to specify the length. This is especially useful if
the function is called with a string that has \0 in the middle
or for chunks of a strings that are not nul terminated.
This is also consistent with most of the other utf8 utils.

Callers inside glib are updated to the new signature.

https://bugzilla.gnome.org/show_bug.cgi?id=779456

Harmonize a little the license headers. In most of the license headers
in GLib, it is "This library".

It is also what is explained at:
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html#SEC4
"How to Apply These Terms to Your New Libraries"

https://bugzilla.gnome.org/show_bug.cgi?id=776586

If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.

It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.

This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.

This needs to be redone with the necessary test fixes.

Simon McVittie authored Oct 13, 2016 and Simon McVittie committed Oct 13, 2016

Based on a patch by Simon van der Linden and rebased onto current GLib,
with improved documentation loosely based on Telepathy's
tp_utf8_make_valid().
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=591603
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=610969

Reviewed-by: Colin Walters <walters@verbum.org>

See https://developer.gnome.org/hig/stable/typography.html

https://bugzilla.gnome.org/show_bug.cgi?id=772221

The function unescape_gstring_inplace was maintaining a line count
without ever making use of it. Drop that.

Avoid an unnecessary branch.

https://bugzilla.gnome.org/show_bug.cgi?id=631597

- GSubprocessLauncher exists since 2.40, not 2.36
- more logical order for g_markup functions
- fix short description of GMarkup
- GMarkupParser: specify that some parameters are NULL-terminated.
- g_string_new (NULL); is possible.
- other trivial fixes.

https://bugzilla.gnome.org/show_bug.cgi?id=728983

Instead of "Return value:".

Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //

Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.

To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.

The C ones, at least.

Strip lots of entity use from |[ ]| examples (which are now
implicit CDATA). Also remove many redundant uses of <!-- -->.

In particular, convert lists to markdown syntax.

Make sure that if we ignore a tag then we also clear the attributes that
we already collected so that they don't end up on the next unignored tag
opening.

Also add some extra brackets for clarity (it doesn't make any difference
-- I just think it reads nicer this way).

https://bugzilla.gnome.org/show_bug.cgi?id=665634

Add a flag to GMarkupParserFlags to ignore qualified tags (along with
their contents) and attributes.

This will provide a nice way for some of our parsers (GDBus
introspection, GSettings schema, etc) to ignore additional tags that
users have added to their files, under a different namespace.

https://bugzilla.gnome.org/show_bug.cgi?id=665634

The code for dealing with </foo> and the second half of <foo/> was
largely duplicated.  We can share a lot of it by using a common
function.

This slightly changes the behaviour of the parser under error
circumstances: previously the parser would deal with '<foo/}' by first
issuing the end_element callback and then flagging the error due to the
unexpected character.  Now we will flag the unexpected character error
first, skipping the callback.

This behaviour change required modifying the testsuite.

https://bugzilla.gnome.org/show_bug.cgi?id=665634

They don't allow that pragma inside functions.

John Ralls authored Sep 28, 2013 and Colin Walters committed Sep 29, 2013

This fixes the build with CLang.

https://bugzilla.gnome.org/show_bug.cgi?id=702516

There were a few places in gmarkup.c where we were giving
pointer differences when integers are expected. Fix that
by explicitly casting to int.

https://bugzilla.gnome.org/show_bug.cgi?id=692079

Henrique authored Jan 13, 2013 and Colin Walters committed Jan 13, 2013

This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).

https://bugzilla.gnome.org/show_bug.cgi?id=691608