The "end" argument is unusual in g_utf8_validate(): it's not a classic out
argument which gets allocated by the called function, but merely points into
one of its input arguments. Thus it is "transfer none".
https://bugzilla.gnome.org/show_bug.cgi?id=672889
There is no need to store a has_trailing_blank_line boolean for
each group, we can just check this at the time we assemble the data.
This fixes a problem without roundtrips where we would sometimes
add an extra blank line between groups.
The testcase here is inspired by
https://bugzilla.gnome.org/show_bug.cgi?id=677817
I didn't do this comprehensively, since there's a lot of it, mainly
due to the GDBus object manager stuff, but anyone trying to use
that would fail fast due to lack of the gdbus code generator.
My main goal was to get API additions to existing classes like
g_data_input_stream_read_line_utf8(), as well as the lower level new
API like glib-unix.h.
https://bugzilla.gnome.org/show_bug.cgi?id=676816
Add a G_SPAWN_SEARCH_PATH_FROM_ENVP flag to GSpawnFlags so that
g_spawn_async() etc use the PATH variable from the passed-in child
environment to search for the executable.
If both this flag and the G_SPAWN_SEARCH_PATH flag are set, the
child environment is searched first and only falls back to the
PATH from the process environment if it is unset.
Bug #676398.
In order for this function to have any point, it has to be possible to
pass non-UTF-8 data to it, so annotate @str as being array-of-guint8
instead of utf8.
https://bugzilla.gnome.org/show_bug.cgi?id=672548
gcc gets upset when we do "((GDestroyNotify) destroy) (_p)" because
it's non-portable. But we don't care; we already know glib wouldn't
work on any platform where different pointer types have different
calling conventions. So tweak the code to avoid the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=674634
On my machine, this test was failing, because the timeout source
for quitting the inner mainloop was triggering repeatedly. Avoid
that by explicitly returning G_SOURCE_REMOVE from the callback.
This reverts commit 79361eede2.
Just commenting out a test without an explanation does not
look right to me. This needs at the minimum a link to a
bug report or an explanation for why the behaviour is platform
dependent. If the test was just wrong, it needs to be removed,
not commented out. If there is a bug in the win32 implementation,
it needs to be fixed.
1) The test was using GCond incorrectly (it always needs a
state variable)
2) The state assertion was racing with the thread; just delete it.
All we're really trying to test here is that the invoke runs by the
time the thread is gone, and the function has an assertion that
it runs in the correct thread.
https://bugzilla.gnome.org/show_bug.cgi?id=674213
When blocking a source that has child sources, we need to consider the
children blocked as well. Otherwise they will still trigger repeatedly
in an inner loop started from the parent source's callback.
https://bugzilla.gnome.org/show_bug.cgi?id=669260
The parsing test needs to make some assumption about the locale
representation of the string to be parsed, so we need to explicitly
override the locale here.
This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
