The current note makes it look like the marshaller code generation has
been deprecated in favour of the libffi-based generic marshaller; this
is not the case, so we should probably clarify the point a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=677235
The old _pcre_ucp_othercase() function was wrong in returning
NOTACHAR (0xffffffff) for characters that aren't changed by upper-
and lower-casing. This led to PCRE internally using incorrect (or
at least inefficient) character classes when using G_REGEX_CASELESS.
E.g. [Z-\x{100}] turned into:
[Z\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{39c}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{fffe}\x{178}z-\x{101}]
instead of the expected and efficient
[Z\x{39c}\x{178}z-\x{101}]
https://bugzilla.gnome.org/show_bug.cgi?id=678273
In general, code using g_slist_delete_link() is broken, because it
potentially requires an O(n) traversal. Just switch to GList in this
case.
The performance hit here was exacerbated by the fact that we were
holding a mutex that needed to be accessed by all threads.
https://bugzilla.gnome.org/show_bug.cgi?id=678576
This is a regression introduced by:
commit 6ac8e6108c
Author: Matthias Clasen <mclasen@redhat.com>
Date: Tue Jun 14 10:12:46 2011 -0400
Don't leak resources in error cases
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
make sure the proxy threads are in the "waiting for a connection"
state when we do the final cleanup, or else there are race conditions
involving which thread processes the GCancellable cancellation first.
The bash-completion code nowadays expects completion files to
be installed in /usr/share/bash-completion/completions, and
expects them to be named like the command they are completing
for.
https://bugzilla.gnome.org/show_bug.cgi?id=677782
Apparently the C4819 warnings appear due to a bug on Visual C++ on DBCS
locales, so re-enable this.
Add a note in the Visual C++ Readme.txt's regarding this.
-gconverterinputstream.c: Avoid GCCism by not using non-standard pointer
arithmetic on void*, but do a cast to char * as that seems to be what the
variable was used for.
-gtestdbus.c: Don't include unistd.h unconditionally, and use g_usleep()
instead of usleep(), as usleep() is not universally available.
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
Otherwise we crash with a null-ptr deref in g_object_newv and ever there we
should not return null, as we're saying that object creation will not return
null.
