Currently, inbuf_size and outbuf_size are not documented as not
nullable, but they are expected to be so, which might lead to unexpected
crashes. Moreover, outbuf itself is also expected to not be null, so
this commit adds the appropriate GI annotations and early returns on
failed preconditions.
In case the OS does not support epoll and kqueue, we get the warning:
gio/tests/pollable.c: In function ‘test_pollable_unix_nulldev’:
gio/tests/pollable.c:266:7: warning: unused variable ‘fd’
[-Wunused-variable]
266 | int fd;
Get rid of it.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Since commit 94b658ab4c, 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.
Spawning a process correctly is a lot more complicated than just bunging
an argument onto the return value from this function.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2901
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
