Since commit 94b658ab4cc86df1352a34f63c9a672abf39f8aa, gwakeup.c has
started using C99 integer types, but has not included <stdint.h>. This
broke building on GNU/Hurd. Fix this by adding the missing include.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
...much like g_string_free_and_steal () does; by redirecting
g_string_free (_, FALSE) calls (when we can detect them) to
g_string_free_and_steal ().
This relies on some unpretty macros, but should be entirely transparent
to any users of g_string_free (). In particular, the macro only
evaluates its arguments once, no matter which branch ends up being
taken. The ternary operator the macro expands to always gets optimized
out, even at -O0: there is only one call to either g_string_free () or
g_string_free_and_steal () in the compiled code, with no run-time
branching.
Add a test for ensuring this works as expected in C++ too.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Now that there is g_string_free_and_steal (), we can use it instead of
the older g_string_free (_, FALSE). Make sure to use its return value
while doing so, as opposed to manually accessing string->str, to avoid
compiler warnings and make the intent more explicit.
This is all done in preparation for making g_string_free (_, FALSE) warn
on unused return value much like g_string_free_and_steal (), which will
happen in the next commit.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
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
We have actual definitions for these functions so we should ignore their
inline versions, not to potentially break doc parsers due to the different
argument names.
For some reasons we can't merge the check together with the gnu C check
if, otherwise the check gets ignored by doc parser.
We could have unguarded crashes when calling strlen (NULL) or when passing
invalid GString's.
Also ensure that we are not using the macro `val` argument multiple times as
it may lead to an unwanted behavior when passing to it a variable value such
as `str[++i]`, as the value may be called multiple times.
C++ tests and Coverity were both underlining this.
Fixes: #2890
Now that the implementation of GSlice has been dropped, these tests for
the internals of the implementation are unnecessary.
We can keep `glib/tests/slice.c` as it tests the API rather than the
implementation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1079
Keep the API for ABI compatibility.
See
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2935#note_1650099
for a summary of the reasoning for this change:
- The performance of system-provided allocators has improved since
GSlice was written, and they are now similarly as performant, or more
performant, than GSlice.
- The code is unmaintained and nobody understands it.
- It doesn’t integrate with tooling and system security features which
have been written for the system `malloc()` implementation (such as
sanitisers, valgrind, etc.).
- It’s confusing for developers: should they use `g_slice_new()` or
`g_new()`?
- GSlice is faster than the libc allocator for allocating and
(particularly) freeing linked lists, but since these are a rubbish
data structure, that’s not a great thing to optimise for.
For the cases where application performance is negatively impacted by
the implementation of GSlice being dropped (and we don’t think there’ll
be many), applications can use a drop-in `malloc()` replacement which is
more suited to their particular workload. Choosing an allocator in GLib
to suit all application workloads is not possible.
Including documentation updates and cleanups by Philip Withnall.
Fixes: #1079
Although unlikely, apparently `message` may be `NULL` (the rest of the
code checks for it), so the code to convert newlines to spaces should
probably also check for `NULL`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Coverity CID: #1504054
When we've a failure our TAP reporting just bails out without that is clear
what is the test that has failed.
So in this case, expose a "not ok" message if the test name is known, and
use it to report the error message too if available.
Otherwise just use the same Bail out! strategy.
This is something that a base test should decide, so if a subtest fails it's
up to the caller to decide whether to bail out the whole suite or just the
subtest.
When using verbose logging, all the printing and the glib info and debug
logs may end up being written in standard out, making meson TAP parser to be
confused and to fail with TAP parsing errors.
So, in such case write the subprocess output all at once using the the gtest
printer so that we add proper formatting.
Also do not write any gtest result message for subprocesses
When using TAP output in gtest, all the printed strings should be commented
not to break the spec, so enforce this at GTest level, by ensuring that
all the lines written via g_print() will be in the commented form and will
respect the subtest indentation.
As per this we can remove some custom code in g_test_log() as now there are
very few cases in which we need to use the default print handler which is
now private when testing.
g_set_print_handler() and g_set_printerr_handler() are supposed to return
the old printer handlers, but in case the default is used NULL is returned
instead.
This makes hard to override the default handler to e.g. decorate the output
with some minor content, without having to rewrite the low-level
implementation.
So, make the default printers to be functions and set them as the default
ones. Also this avoids having to check each time what function to use at
print time.
