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.
When looking up signals by name (to connect, for example) and the named
signal cannot be found on the given instance, report the type of the
instance.
This is quite a lot more useful as a diagnostic message than only a
memory address.
https://bugzilla.gnome.org/show_bug.cgi?id=694350
