Unicode corrigendum #9 spells out in no uncertain terms that on
conversion interfaces we should not reject characters like U+FFFE and
U+FFFF which we were doing before.
Commit f91ef4ef15 started accepting these
characters, but we had some testcases that were checking that strings
containing these characters should be rejected.
Update the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=694669
Commit f641699 (for bug 675333) introduced a check whether the Exec= program in
a .desktop actually exists. This broke the /appinfo/mime/* test cases which use
executable names like "my_app".
Use real ones instead (like "echo" and "sleep"), and add a new
/appinfo/mime/ignore-nonexisting test case which verifies that
g_desktop_app_info_new() indeed ignores nonexisting executables.
https://bugzilla.gnome.org/show_bug.cgi?id=695191
I added these because the older mingw32 toolchain didn't have
MemoryBarrier(). The newer mingw-w64 toolchain however has.
As reported by John Emmas this was causing build failure with
MSVC because of inline issues. But that reminded me that we
may be taking this path even if the system implements
MemoryBarrier as a function, which is a waste. So, just remove
it.
The newer Microsoft CRTs (8.0/2005 and later) impose much stricter
(paranoid) checks on close() being doubly called and the use of
invalid file descriptors. This makes the calls on the file descriptors
use more caution when using them and only call close() when necessary.
This also adds an (empty) invalid parameter handler* as required by the
newer Microsoft CRTs to prevent the system from aborting the process
when we are checking whether a file descriptor is valid.
[*]: http://msdn.microsoft.com/en-us/library/a9yf33zb.aspxhttps://bugzilla.gnome.org/show_bug.cgi?id=693646
Add entry for __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, to better reflect the
entries of items in config.h.in. We are not currently defining this here
as the pre-configured config.h.win32.in is primarily meant for Visual
Studio builds of GLib-the MinGW/GCC/Clang builds of GLib will normally
use the autotools builds, which should give the correct config.h entries
upon running ./configure.
Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
We can detect list corruption in some cases. The new test case
demonstrates a case where we can warn instead of silently corrupt
the list. This was pointed out by Steve Grubb.
Also, use the same auxiliary routine in all places where we unlink
a list element.
