Since PCRE 8.03, PCRE supports backtracking control verbs with a name argument.
g_match_info_get_mark() will return the argument of the last encountered verb
in the whole matching process for failed or partial matches, and in the matching
path only for matches.
Since PCRE 8.00 it supports a variant of PCRE_NOTEMPTY that works
similarly except that it only applies to the start of the matched string
but permits empty matches further in.
g_regex_get_compile_get_compile_flags() and g_regex_get_match_flags()
were leaking PCRE flags that don't exist in the corresponding
public GRegexCompileFlags and GRegexMatchFlags; this change masks
these internal flags.
Due to load, particular traits of the architecture, or other circumstances, the
/mainloop/timeouts sometimes manages to call the "every
100 ms" timer loop only 9 times in 1050 ms.
This is an inherent race-condition in the test; allow it some slack and accept
9 times as well.
https://bugzilla.gnome.org/show_bug.cgi?id=678959
They make a full (deep) copy of a list.
In contrast with g_[s]list_copy(), these functions take a function as a argument
to make a copy of each list element, in addition to copying the list container itself.
The functions g_[s]list_copy() were reimplemented to just call the new functions
with NULL as the function argument, which will behave like current implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=675024
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
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
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.
I added a setlocale call, because we need it for Unicode to
come out right; but I forgot to fix the locale, so we now
fail when comparing error messages to the expected (English)
result. Correct this by setting LANG explicitly to en_US.utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=669285
Or some system with different locale settings might get confused whether
a two digit year is to be parsed with regard to the current century or
as an absolute year.
Add a test that excercises the script execution code.
Unfortunately, much of this code only runs in the forked
child, and therefore its execution does not get caught
by gcov.
