The functions g_strconcat, g_strjoinv and g_strjoin perform the
concatination of strings in two phases. The first phase figures out the
required amount of memory to hold the resulting string. The second
phase actually copies the strings into the allocated memory.
If the sum of the lengths of all strings to be joined exceeds G_SIZEMAX,
then phase two triggers an out of boundary write due to insufficient
amount of memory allocated.
While this sounds impossible to do at first, actually it becomes a
possibility on 32 bit systems with merely 20 MB of heap. The overflow
can actually happen if the same string is joined multiple times. See
attached unit test. While the same can be done with 64 bit systems, it
takes much more memory and a lot of time.
Fortunately the protection is rather cheap, although it adds two or
three machine instructions and branches due to testing.
If string operations get the length G_MAXSIZE passed (which cannot
ever be true because terminating NUL byte would not fit), return NULL
instead of triggering out of boundary writes.
It turns out it’s not actually been explicitly tested before, even
though it has full code coverage through being called by other code
which is tested.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
There are a couple of places in the code which use `isnan()` and have
platform-specific workarounds for it. Unify those, and extend the
workaround to work for msys2-mingw32.
It seems that msys2-mingw32 can’t automatically use `isnan()` in a wider
mode than `float`:
```
In file included from ../glib/gdatetime.c:60:
../glib/gdatetime.c: In function 'g_date_time_new':
../glib/gdatetime.c:1648:14: error: conversion from 'gdouble' {aka 'double'} to 'float' may change value [-Werror=float-conversion]
1648 | isnan (seconds) ||
| ^~~~~~~
cc1.exe: all warnings being treated as errors
```
See: https://gitlab.gnome.org/pwithnall/glib/-/jobs/4022715
Using it in float mode on all platforms should not change behaviour, as
a conversion from `(double) NAN` to `float` should still give `NAN`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
g_strdup() is often used to duplicate static strings, in these cases the
compiler could use a faster path because it knows the length of the
string at compile time, but this cannot happen because our g_strdup()
implementation is hidden.
To improve this case, we add a simple implementation of g_strdup() when
it is used with static or NULL strings that explicitly uses strlen,
g_malloc and memcpy to give hints to the compiler how to behave better.
This has definitely some benefits in terms of performances, causing an
iteration of 1000000 string duplication to drop from 2.7002s to 1.9428s
for a static string and from ~0.6584s to ~0.4408 for a NULL one.
Since compiler can optimize these cases quite a bit, the generated code
[2] is not increasing a lot, given that it can now avoid generating some
code or do it in few simpler steps.
Update tests to cover both inlined and non inlined cases.
[1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3209#note_1644383
[2] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3209#note_1646662
The new macro form of `g_str_equal()` had stricter type checking than
the original function form. That would be nice, except it causes new
compiler warnings in third party projects, which counts as an API break
for us, so unfortunately we can’t do it.
Add some tests to prevent regressions on this again.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2809
g_str_has_prefix uses G_UNLIKELY itself, and up
until recently, G_UNLIKELY could not be nested.
This commit adds a test that nests G_UNLIKELY to
make sure it continues to work going forward.
Some of GLib's unit tests are under an apparently GLib-specific
permissive license, vaguely similar to the BSD/MIT family but with the
GPL's lack-of-warranty wording. This is not on SPDX's list of
well-known licenses, so we need to use a custom license name prefixed
with LicenseRef if we want to represent this in SPDX/REUSE syntax.
Most of the newer tests seem to be licensed under LGPL-2.1-or-later
instead.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise clang would complain:
../glib/tests/strfuncs.c:2603:32: warning: result of comparison
against a string literal is unspecified (use an explicit string
comparison function instead) [-Wstring-compare]
g_assert_true ((gpointer)str != (gpointer)"");
^ ~~~~~~~~~~~~
../glib/gtestutils.h:187:59: note: expanded from macro 'g_assert_true'
if G_LIKELY (expr) ; else \
^~~~
../glib/gmacros.h:1186:59: note: expanded from macro 'G_LIKELY'
#define G_LIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 1))
^~~~
../glib/gmacros.h:1180:8: note: expanded from macro '_G_BOOLEAN_EXPR'
if (expr)
* Add a test to check that smaller string than prefix/suffix are
handled in g_str_has_*() functions.
* Add a tests on macro prefixed function and ensure that function
itselves are tested as well.
This is like our other suite of g_set_*() based APIs to simplify and
improve correctness of setters for fields, properties, and more.
This implementation specifically handles setting string values that may
point to an offset within the current string by copying before free.
strcmp() is used directly (as opposed to g_strcmp0() due to it being in
gtestutils.h as well as to increase the chance that the compiler will
hoist the implementation.
Fixes#2747
Unfortunately, `g_memdup()` accepts its size argument as a `guint`,
unlike most other functions which deal with memory sizes — they all use
`gsize`. `gsize` is 64 bits on 64-bit machines, while `guint` is only 32
bits. This can lead to a silent (with default compiler warnings)
truncation of the value provided by the caller. For large values, this
will result in the returned heap allocation being significantly smaller
than the caller expects, which will then lead to buffer overflow
reads/writes.
Any code using `g_memdup()` should immediately port to `g_memdup2()` and
check the pointer arithmetic around their call site to ensure there
aren’t other overflows.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2319
This will replace the existing `g_memdup()` function, which has an
unavoidable security flaw of taking its `byte_size` argument as a
`guint` rather than as a `gsize`. Most callers will expect it to be a
`gsize`, and may pass in large values which could silently be truncated,
resulting in an undersize allocation compared to what the caller
expects.
This could lead to a classic buffer overflow vulnerability for many
callers of `g_memdup()`.
`g_memdup2()`, in comparison, takes its `byte_size` as a `gsize`.
Spotted by Kevin Backhouse of GHSL.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: GHSL-2021-045
Helps: #2319
It may be defined by the environment (we document that as being allowed)
— if so, individual files should not try to redefine it, as that causes
a preprocessor warning.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is a utility function which I find myself writing in a number of
places. Mostly in unit tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It’s perverse, but explicitly documented that strtoull() accepts numbers
with a leading minus sign (`-`) and explicitly casts them to signed
output.
g_ascii_strtoull() is documented to do what strtoull() does (but locale
independently), and its behaviour is correct. However, the documentation
could be a lot clearer about this unexpected behaviour.
Add a unit test for it too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Very often when we want to convert a string to number, we assume that
the string contains only a number. We have g_ascii_strto* family of
functions to do the conversion but they are awkward to use - one has
to check if errno is zero, end_ptr is not NULL and *end_ptr points to
the terminating nul and then do the bounds checking. Many projects
need this kind of functionality, so it gets reimplemented all the
time.
This commit adds some replacement functions that convert a string to a
signed or unsigned number that also follows the usual way of error
reporting - returning FALSE on failure and filling an error output
parameter.
Add a check to configure.ac for strerror_r, since we don't currently
require POSIX.1-2001 conformance in general. Add back a
plain-strerror() case as a fallback, and rearrange the glibc-vs-POSIX
strerror_r() branches.
Update the docs to not claim that "not all platforms support the
strerror() function" (we require C90), but still mention the UTF-8 and
always-valid-string benefits. (And make test_strerror() check that
last part.)
https://bugzilla.gnome.org/show_bug.cgi?id=754788
Skip the tests on inf/nan strings for the gvariant and strfuncs tests, and
skip the hex strings for the strtod tests in strfuncs as they are C99
features that are not yet supported by Visual C++ (even 2013). Use a
definition for NAN and INFINITY (that is also used in PyGObject) as
atof("NaN") and atof("Infinity") simply returns 0.0 (which is not a NAN)
in Visual C++ to fix the tests running there.
Also adapt to the format of g_ascii_formatd() when dealing with 1e99.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
This has uncovered two unused testcases in option-context.c. They are
currently broken and require more investigation (which is probably why
they are unused).
