If a path starts with more than two slashes, the `start` value was
previously incorrect:
1. As per the `g_path_skip_root()` call, `start` was set to point to
after the final initial slash. For a path with three initial
slashes, this is the character after the third slash.
2. The canonicalisation loop to find the first dir separator sets
`output` to point to the character after the first slash (and it
overwrites the first slash to be `G_DIR_SEPARATOR`).
3. At this point, with a string `///usr`, `output` points to the second
`/`; and `start` points to the `u`. This is incorrect, as `start`
should point to the starting character for output, as per the
original call to `g_path_skip_root()`.
4. For paths which subsequently include a `..`, this results in the
`output > start` check in the `..` loop below not skipping all the
characters of a preceding path component, which is then caught by
the `G_IS_DIR_SEPARATOR (output[-1])` assertion.
Fix this by resetting `start` to `output` after finding the final slash
to keep in the output, but before starting the main parsing loop.
Relatedly, split `start` into two variables: `after_root` and
`output_start`, since the variable actually has two roles in the two
parts of the function.
Includes a test.
This commit is heavily based on suggestions by Sebastian Wilhemi and
Sebastian Dröge.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
oss-fuzz#41563
The tests were previously only checking the macro forms. The function
forms should behave identically, but since it’s easy enough to get
coverage of them, we might as well.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This decreases the overall test time from 0.17s to 0.12s for me, and
will help further in the following commit where I’m going to repeat some
of these calculations again for further comparisons.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Previously tests existed in two places,
`$top_srcdir/tests/sources.c` contained additional tests,
they have now been moved to `$top_srcdir/glib/tests/mainloop.c`
and `$top_srcdir/tests/sources.c` was deleted.
Related to: #1434
Notifying during object destruction is a dubious "feature": objects
might end up recreating a bunch of state just before clearing it;
language bindings might get spurious notifications during garbage
collection runs.
We freeze the notification queue before running the dispose() chain; if
the object was temporarily vivified during dispose, we thaw the
notification queue, otherwise we let the instance clear it when we
finalize it.
See: https://gitlab.gnome.org/GNOME/gjs/-/issues/445
Previously tests existed in two places,
`$top_srcdir/tests/qsort-test.c` contained a similar test
to the one in `$top_srcdir/glib/tests/sort.c` called `test_sort_basic()`
The test for checking with zero elements was additional added to
`$top_srcdir/glib/tests/sort.c` and `$top_srcdir/tests/qsort-test.c`
was deleted.
Related to: #1434
Improve the performance of canonicalising filenames with many `..` or
`.` components, by modifying the path inline rather than calling
`memmove()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2541
Added `g_alloca0()` which wraps `g_alloca()` and initializes
allocated memory to zeroes.
Added `g_newa0()` which wraps `g_alloca0()` in a typesafe manner.
Refreshed and tweaked by Nishal Kulkarni.
The charset set in `CHARSET` overrides the charset after the `.` in any
`LC_*` category (set via the environment or `setlocale()`). This will
break many tests, but in particular it definitely breaks the
`/GDateTime/format_mixed/` tests which are specifically checking
different charsets being set for different `LC_*` categories.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2514
Users should probably never be setting this — instead, just add the
charset after a `.` in `LANGUAGE`/`LC_ALL`/`LC_*`/`LANG`.
I can’t find any reference (in `git log`, code comments, or man pages)
to this environment variable being standardised or documented or even
used anywhere outside GLib. Perhaps it should eventually be removed.
If anybody finds references as to why GLib checks `CHARSET`, this
comment can be updated in future.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2514
De-duplicate g_nearest_pow() implementation and add some overflow protections to g_ptr_array_maybe_expand(), g_string_maybe_expand() and g_string_chunk_insert_len()
See merge request GNOME/glib!2368
If the new string's length plus the existing storage's length is
overflowing a gsize, we would previously memcpy() the string over the
bounds of the previous allocation.
Similarly if the string's size was bigger than G_MAXSIZE / 2 we would've
previously allocated 0 bytes.
Now instead create a new allocation that fits the string.
It might otherwise happen that the return value from g_nearest_pow()
does not fit into a guint, i.e. it might be G_MAXUINT + 1 if that fits
into a gsize.
