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>
It was possible to pass in (for example) an invalid hour to
g_date_time_new_ordinal(), which would be passed on to
g_date_time_new(), which would (correctly) return `NULL` — but then
g_date_time_new_ordinal() would try to dereference that.
Includes some test cases.
oss-fuzz#16103
oss-fuzz#17183
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Support for custom allocators was dropped in
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
The introductory doc text for the gmem APIs still warns against mixing
malloc/free with g_malloc/g_free. Clarify upfront in the docs that these
two sets of APIs are now guaranteed to use the same memory allocator &
can thus their usage can be freely mixed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
g_utf8_get_char_validated() was not exactly matching its
documentation. The function was not checking if the sequence of
unicode characters was free of null bytes before performing a more
in-depth validation.
Fix issue #1052
The static analyser can’t yet work out how `g_autofree` works, so
disable those tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
The macros for the probes confuse the static analyser, and are often
called with arguments which the analyser things shouldn’t be used any
more (for example, the address of a block of memory which has just been
freed).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1767
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
It’s confusing and often doesn’t help the user. Match the error code and
come up with a more UI-appropriate error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the user has `CAP_DAC_OVERRIDE` or similar (for example, if running
the tests as root), the `mkdir-with-parents-permission` test is skipped.
The check for `CAP_DAC_OVERRIDE` was by creating a subdirectory of the
test directory. That subdirectory, however, was never removed, which
caused a ‘directory not empty’ error when trying to delete the test
directory.
Fix that by correctly deleting the subdirectory if skipping the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
clang will warn with -Wunused-function if the g_autoptr macros are
ever used inside a .c file. This would break a lot of -Werror builds
with clang.
Mark such functions as explicitly unsed so clang will not warn about
them.
However, it's fine to call it when building for the debug target
(which uses the debug CRT and hence sets -D_DEBUG), so let's keep that
around.
The Windows App Certification Kit only runs on apps built in release
mode.
These macros wrap functions which were only introduced in certain
versions of GLib. The functions are correctly marked as introduced in
those versions, but the macros aren’t, which can result in not getting
appropriate deprecation warnings if you’re using those APIs when you
have said you’re targeting older GLib versions using
`GLIB_VERSION_MAX_ALLOWED`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #1860
We require a newer SDK version now, so this is not needed.
Specifically, we set _WIN32_WINNT to 0x0601, which sets our SDK
requirement to Windows 7+, and this code is only needed for MSVC 5.0,
which is ancient.
It’s confusing and often doesn’t help the user. Match the error code and
come up with a more UI-appropriate error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If the dup(stderr) returns '-1' (an error occured), then the program
shouldn't call a 'close(stderr); dup(old_err);' after the exec() failed.
Fix issue #1880
A static analysis run noted that we weren't freeing the cmdline in the
error path here. We can just make this an assertion instead; I just
checked the kernel code, and it just usees a seq_printf() here which
will NUL terminate.
This fixes the following warning, by making the compiler checks for the
`pop` match those for the `push`:
```
[221/1124] Compiling C object 'glib/tests/d796b50@@mem-overflow@exe/mem-overflow.c.o'.
../glib/tests/mem-overflow.c:204:24: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas]
#pragma GCC diagnostic pop
```
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When g_variant_get_child_value() is called for a child whose
serialisation is an empty byte string (which is possible), `bytes_data`
will be non-`NULL`, but `data` may be `NULL`. This results in a negative
offset being passed to `g_bytes_new_from_bytes()`, and a critical
warning.
So if `data` is `NULL`, set it to point to `bytes_data` so the offset is
calculated as zero. The actual value of the offset doesn’t matter, since
in this situation the size is always zero. An offset of zero is never
going to cause problems.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1865
These are copies of the existing tests for `g_time_val_from_iso8601()`,
with the test strings which fail for `GDateTime` commented out. This is
OK, as it’s documented as only accepting a subset of ISO 8601 (and for
some of the test vectors, it’s debatable whether they’re actually valid
ISO 8601, depending on how you interpret the valid bounds of timezone
offsets — some interpretations of the available documentation would say
that timezone offsets should never be ≥24 hours or ≥60 minutes).
There is one test string which is not accepted by
`g_time_val_from_iso8601()` but which is accepted by `GDateTime`, as
`g_date_time_new_from_iso8601()` actually accepts RFC 3339, which is a
little more liberal than ISO 8601. Fun times. See
https://tools.ietf.org/html/rfc3339#section-5.6.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some malformed ISO 8601 date/time strings were causing an assertion
failure when passed to `g_date_time_new_from_iso8601()`, due to a
mismatch between the bounds checking of timezone offsets in `GDateTime`
and `GTimeZone`. Fix that and add a unit test for it.
oss-fuzz#16101
Signed-off-by: Philip Withnall <withnall@endlessm.com>
