This means that the test can't build on Windows (and we do want it there).
This will be properly resolved with bug 725266, but let's not block the
build before then.
https://bugzilla.gnome.org/show_bug.cgi?id=724859
For now, we are mainly interested in G_MARKUP_TREAT_CDATA_AS_TEXT.
This commit makes markup-parse look for expected output files with
the extension .cdata-as-text in addition to .expected, and compares
the output of parsing with G_MARKUP_TREAT_CDATA_AS_TEXT against
them. markup-parse --cdata-as-text foo.gmarkup can be used to produce
such expected output.
Simplify our tracking of issued source id integers and fix some bugs.
Previously the source's id was remove from the 'used' table from
source_remove_from_context() which was also called if the source
priority was changed (in which case it would never be added back to the
table). The source id could be reissued in that case.
In the new approach, we just always keep a hash table of sources, by
source id. This simplifies the logic and will also allow us to improve
performance of g_main_context_find_source_by_id() which is called in some
fairly common cases, such as g_source_remove(). These improvements will be in
the following commits.
https://bugzilla.gnome.org/show_bug.cgi?id=724839
88182d375e caught this issue in
g_async_queue_timed_pop() but failed to fix the same bug in the _unlocked()
variant.
This is only a problem on 32bit systems. On 64bit systems, the tv_sec
in a timeval is already 64 bits, so no overflow occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=722604
Clarify that _add_poll() _remove_poll() _add_unix_fd(),
_modify_unix_fd(), _remove_unix_fd(), _query_unix_fd(),
_set_ready_time(), _add_child_source() and _remove_child_source() are only
intended to be used by the implementation of a particular GSource -- not its
consumers.
https://bugzilla.gnome.org/show_bug.cgi?id=724707
g_main_context_acquire() mentions that you must have called it before
you make any calls to _prepare(), _query(), _check() or _dispatch().
For emphasis, add a note on each of those functions pointing back to the
fact that you must have called _acquire() before using them.
Due to its unusual interface, I suspect that nobody is using
g_main_context_wait() but there is no way to know.
Add a critical notice that will be displayed if anyone calls the
function, asking them to file a bug with us.
We'll let this go out with the 2.40 release and see if we get a response
before we proceed with actually breaking the functionality.
Make sure this call succeeds, aborting if it doesn't
This will prevent people from having to waste time chasing down the problems
that would otherwise be caused by this silent failure.
We now depend on CLOCK_MONOTONIC, but it's possible that people may
attempt to run GLib on systems where it isn't supported at runtime.
Check the return value of clock_gettime() and abort() if it fails in
order to save these people from wasting time on debugging a tricky
issue.
https://bugzilla.gnome.org/show_bug.cgi?id=670144
Add a note to the documentation that child sources cannot have their priority
changed independently from their parent. Add a g_return_if_fail() to the
public API in order to enforce this.
This was already a reality due to the check in
g_source_set_priority_unlocked(), but it was never explicitly documented.
https://bugzilla.gnome.org/show_bug.cgi?id=724706
Add a new function, g_str_to_ascii() that does locale-dependent ASCII
transliteration of UTF-8 strings.
This function works off of an internal database. We get the data out of
the localedata shipped with glibc, which seems to be just about the best
source of locale-sensitive transliteration information available
anywhere.
We include a update script with this commit that's not used by anything
at all -- it will just sit in git. It is intended to be run manually
from time to time.
https://bugzilla.gnome.org/show_bug.cgi?id=710142
We've had a relatively rocky path with g_cond_wait_until() on systems
that either don't support pthread_condattr_setclock() or where
g_get_monotonic_time() is not based on CLOCK_MONOTONIC (ie: Android and
Mac OS).
Fortunately, both of these platforms seem to share
pthread_cond_timedwait_relative_np() which allows us to implement
g_cond_wait_until() without races.
With this patch, we now require that one of pthread_condattr_setclock()
or pthread_cond_timedwait_relative_np() exists. A quick look around
suggests that this is true for all platforms that we care about.
This patch removes our use of pthread_cond_timedwait_monotonic() and
pthread_cond_timedwait_monotonic_np() which were Android-only APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=673607
We now assume the existence of clock_gettime() and CLOCK_MONOTONIC as
specified by POSIX.1-2001. This means that we always return truly
monotonic time, which will prevent problems in the case that the user
changes the time.
Mac OS doesn't have clock_gettime() but it does have
mach_absolute_time(), so we can use that there.
We keep our Windows case as well (although we should simplify it once XP
hits EOL later this year).
This patch removes the fallback to gettimeofday() in case of missing
clock_gettime(). We no longer have any way to test this codepath and
therefore it must go.
This patch also restructures the #ifdef a bit so that we repeat the
entire function definition inside of #ifdef instead of just the entire
body of one function.
https://bugzilla.gnome.org/show_bug.cgi?id=724687
g_assert_true(), g_assert_false(), g_assert_null(), and
g_assert_nonnull() simply printed out the expression they were
checking, without any further explanation of what went wrong. (In
particular, "g_assert_true(x)" and "g_assert_false(x)" would both
print the same thing on failure.) Add a little bit more context.
https://bugzilla.gnome.org/show_bug.cgi?id=724385
We have a configure.ac check for lib.exe that attempts to enable
creation of .lib files for our 5 public libraries. That has been broken
for a long time for two reasons:
1) the Makefiles hardcode 'lib' instead of 'lib.exe'
2) we dropped generation of .def files quite some time ago (except for
in gthread where we have the two-symbol file under version control)
Add new rules for creating .def files from dumpbin.exe (which you should
have if you have lib.exe) and fix the .lib rules to use lib.exe.
Add a bit of $(AM_V_GEN) all around, as well.
https://bugzilla.gnome.org/show_bug.cgi?id=722033
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
If we used a non-positive pid, we'd call waitpid(that_pid, ...)
which is exactly the situation this function can't deal with.
On Windows, GPid is a HANDLE (pointer), so I don't think the same thing
applies.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=723743
Reviewed-by: Ryan Lortie
In particular, it is not incorrect to g_return_if_fail (..., FALSE)
in a function returning a "success" gboolean and a GError: "failure to
meet the preconditions is an error" takes precedence over the
GError documentation's guarantee that the error will be set on failure.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=660809
Reviewed-by: Emmanuele Bassi
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
We are a bit too aggressive about freeing memory in strv mode. Only
free it in the case that we actually set the pointer to NULL.
Uncovered by the GApplication tests.
Slightly expand on the documentation about casting varargs when
constructing GVariants, and link to it from all the functions where it’s
a necessary consideration.
Add an example of passing flags to a ‘t’ type variable (guint64).
Assuming the flags enum does not have many members, the flag variable
will be 32 bits wide, and needs an explicit cast to be passed into
g_variant_new() as a 64-bit value.
https://bugzilla.gnome.org/show_bug.cgi?id=712837
We need to re-get the size of tzi.DaylightName before we call
RegQueryValue() because the buffer might not have enough room to hold the
value for tzi.DaylightName that would be acquired by RegQueryValueExA(),
even though the size of tzi.DaylightName and tzi.StandardName is the same.
This is a pitfall of RegQueryValue()[1] as not doing this can result in an
ERROR_MORE_DATA (234) failure, causing the acquisition of tzi.DaylightName
to fail.
This will fix the gdatetime/equal test, amongst some other tests in
gdatetime, at least on certain non-English version of Windows.
[1]: http://social.msdn.microsoft.com/Forums/vstudio/en-US/84f90854-e90c-4b63-8fc1-655a0b4645fd/regqueryvalueex-returns-errormoredatahttps://bugzilla.gnome.org/show_bug.cgi?id=719344
Adds some code examples how functions can be used. Adds a hint
to look at GQueue if access to the start and the end of the list
is required.
applying comments from Emmanuele Bassi and adds some more
improvements to clarify how functions should be used.
https://bugzilla.gnome.org/show_bug.cgi?id=683388
GLib has a pervasive assumption that function and data pointers are
basically interchangeable, which is true in all modern ABIs,
but not actually guaranteed by ISO C. If someone tries to use GLib on a
platform where function and data pointers are different sizes, fail early.
https://bugzilla.gnome.org/show_bug.cgi?id=688406
It is possible (but unlikely) that there will be a non-empty list of
pending dispatches when we remove the last ref from a GMainContext.
Make sure we drop the refs on the sources appropriately.
Add a (now-working) testcase that demonstrates how to trigger the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=139699
Add a note to the overview documentation for GOptionContext about why
you need to be careful about argv encoding on UNIX and about why you
should avoid argv entirely on Windows. Mention some possible
alternative approaches, including a code example.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
This returns the command line in GLib filename encoding format (ie:
UTF-8) for use with g_option_context_parse_strv().
This will allow parsing of Unicode commandline arguments on Windows,
even if the characters in those arguments fall outside of the range of
the system codepage.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Add another difference to the freshly-added g_option_context_parse_strv:
now, on Windows, its arguments on to be in UTF-8 instead of the argv[]
encoding (from the system codepage).
The documentation teases g_win32_get_command_line() which is a new
GLib-filename-encoding-based function that will be added in a following
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
Use the new g_option_context_parse_strv() to patch up some leaks in some
insufficiently-argv-emulating testcases in option-context.c.
This gives some test coverage of the new function while also making
option-context now leak-free.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
Add g_option_context_parse_strv() that obeys the normal memory conventions for
dealing with a strv instead of assuming that we're dealing with the 'argv'
parameter to main().
This will help for using GOptionContext with GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=721947
The names of the month (and abbreviations) are specific to the Windows
system locale, so we need to use SetThreadLocale() to set the locale of
the running program to en-US so that it will parse "March" and "Sept" etc.
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Windows will not allow one to write to a temp file opened by g_mkstemp()
by opening another fd associated with it before one closes the fd that
is returned by g_mkstemp(), which will cause the test_save test to fail.
Fix this by using a variable to store the fd from g_mkstemp() and checking
it, and call close() on that variable before attempting to call
g_key_file_save_to_file() on the temp file as that will attempt to open
another fd (which would not work) associated with that temp file.
https://bugzilla.gnome.org/show_bug.cgi?id=719344
Fix some races introduced in be2c7b83c4
while keeping the property that multiple handlers for the same unix
signal all get dispatched.
Also fix the behaviour of the source checking for pending signals when
it's created. No matter what we do here (clear the pending flag or not)
there is something that can go wrong.
If we clear the flag, we may prevent other sources from being
dispatched. If we don't clear it, we may end up dispatching the same
source twice (if we manage to dispatch it from its own thread before the
GLib worker has a chance to run).
Instead, run the full dispatch procedure when a new source is added. It
actually doesn't matter what thread this runs in since the lock is held.
https://bugzilla.gnome.org/show_bug.cgi?id=711090
The existing tests were accidentally using the same test data
twice. Fix that, and add another set of tests that exercise
the filename collation special cases.
g_time_val_from_iso8601 was attempting to parse strings
having only a date, but failed to actually set the timeval
despite returning TRUE. Since the docs state that the function
only parses strings containing a date and a time, just return
FALSE in this case.
Also remove an incomplete testcase for this behaviour that was
just checking the boolean return value, but not timeval.
This was a feature intended from the very beginning that somehow never
got written. It's a way to replace these sort of error messages out of
the GVariant parser:
1-2,10-15:unable to find a common type
with something in the style of the Vala compiler:
unable to find a common type:
[1, 2, 3, 'str']
^ ^^^^^
https://bugzilla.gnome.org/show_bug.cgi?id=715028
Most GErrors, such as GSomethingError, have a function to get
their quark that looks like g_something_error_quark(),
so bindings (such as gtkmm) would expect GVariantParseError
to have g_variant_parse_error_quark(). Instead this had
g_variant_parser_get_error_quark().
This deprecates the old function and adds the correct one,
making life easier for gtkmm (and maybe others).
https://bugzilla.gnome.org/show_bug.cgi?id=708212
Change g_test_run() to return 1 on failure (rather than the number of
failed tests), and 77 if all tests are skipped (since automake and
some other test harnesses recognize that status code).
Previously g_test_run() returned the number of failed tests, but this
behavior was not documented, and at any rate, prior to 2.39,
g_test_run() would normally not return at all if an error occurred.
https://bugzilla.gnome.org/show_bug.cgi?id=720263
Allow g_test_trap_subprocess() to be used in a simple cases by
rerunning the same test case itself. This is accomplished by
passing %NULL as the test case name.
https://bugzilla.gnome.org/show_bug.cgi?id=720236
Since we are already building a deprecated function for compatibility
reasons, we don't really need to see a warning when it uses another
deprecated GLib function.
Commit e53caad4 makes _g_log_abort() noreturn by calling abort()
unconditionally.
However, it is useful to be able to skip some log_abort() with a
debugger, to reach a point of interest. Revert back to previous
behaviour. Make g_assert_warning() noreturn by calling abort().
https://bugzilla.gnome.org/show_bug.cgi?id=711800
When calculating the array sizes in get_contents_stdio(), there is a
possibility of overflow for very large files. Rearrange the overflow
checks to avoid this.
The code already handled some possibilities of files being too large, so
no new GError has been added to handle this; the existing
G_FILE_ERROR_FAILED is re-used.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
This probably won’t crash, as it can only happen if (size == 0), but
add a check to be safe, and to shut up the static analyser.
This case can be reached with the following call:
gvs_read_unaligned_le(NULL, 0)
which can be called from:
gvs_tuple_get_child(value, index_)
with (value.data == NULL) and (value.size == 0).
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=715164
Don't attempt to insert environmental variables in the hash table during
the test listenv that is an empty string, as GetEnvironmentStringsW() also
returns special enviroment variables which have empty strings as their
variable names, at least on Windows 7 and 8.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Make some of the conversion functions a bit more friendly to allocation
failure.
Even though the glib policy is to abort() on allocation failure by
default, it can be quite helpful to return an allocation error for
functions already providing a GError.
I needed a safer g_utf16_to_utf8() to solve crash on big clipboard
operations with win32, related to rhbz#1017250 (and coming gdk handling
bug).
https://bugzilla.gnome.org/show_bug.cgi?id=711546
g_test_init() was calling _g_messages_set_exit_on_fatal() from
subprocesses, to make fatal log messages call _exit() rather than
abort(), but the function name is sort of confusing, and we don't
really need it anyway, since g_log() can just call g_test_subprocess()
instead and decide for itself.
Likewise, update g_assertion_message() to do the check itself, rather
than calling into gmessages to do it, and fix
g_assertion_message_expr() to also check whether it should exit or
abort. (Previously it always called abort(), although this didn't
actually matter since that was dead code until
test_nonfatal_assertions was added.)
https://bugzilla.gnome.org/show_bug.cgi?id=711800
g_test_set_nonfatal_assertions() was a no-op, because
g_assertion_message() wasn't actually checking the
test_nonfatal_assertions flag. Fix that and add a test.
Also, g_test_set_nonfatal_assertions() has to set test_mode_fatal to
FALSE as well, or else a failed assertion will cause the test program
to abort at the end of the failed test.
Also, belatedly add this and the new g_assert_* methods to the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=711800
g_array_remove_range and g_byte_array_remove_range return
a pointer to the array, g_ptr_array_remove_range returns
void. Since it is pretty harmless, make it return the array
too.
https://bugzilla.gnome.org/show_bug.cgi?id=159528
Declare that the previously-unused "..." argument to g_test_init() is
actually a NULL-terminated list of strings indicating testing options,
and add an option "no_g_set_prgname", which keeps g_test_init() from
calling g_set_prgname(). Then we can port glib/tests/option-argv0 to
use gtester, by passing that option.
https://bugzilla.gnome.org/show_bug.cgi?id=711796
In Windows development environments that have it, <unistd.h> is mostly
just a wrapper around several other native headers (in particular,
<io.h>, which contains read(), close(), etc, and <process.h>, which
contains getpid()). But given that some Windows dev environments don't
have <unistd.h>, everything that uses those functions on Windows
already needed to include the correct Windows header as well, and so
there is never any point to including <unistd.h> on Windows.
Also, remove some <unistd.h> includes (and a few others) that were
unnecessary even on unix.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume unix platforms support the original POSIX.1 standard.
Specifically, assume that if G_OS_UNIX, then we have chown(),
getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
<sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
Additionally, since all versions of Windows that we care about also
have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
Also remove one include of <sys/times.h>, and the corresponding
configure check, since the include is not currently needed (and may
always have just been a typo for <sys/time.h>).
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Assume all supported platforms implement C90, and therefore they
(correctly) implement atexit(), memmove(), setlocale(), strerror(),
and vprintf(), and have <float.h> and <limits.h>.
(Also remove the configure check testing that "do ... while (0)" works
correctly; the non-do/while-based version of G_STMT_START and
G_STMT_END was removed years ago, but the check remained. Also, remove
some checks that configure.ac claimed were needed for libcharset, but
aren't actually used.)
Note that removing the g_memmove() function is not an ABI break even
on systems where g_memmove() was previously not a macro, because it
was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
it would have been glib-internal since 2004.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Remove workarounds for NeXTStep (last released in 1995), SunOS (1994),
HP-UX 9.x (1992) and 10.x (1995), OSF/1 / Digital UNIX / Tru64 UNIX
4.x (1999), and AIX 4.x (1999).
HP-UX 11 implements dlopen(), so dropping support for earlier versions
also lets us remove the HP-UX-specific gmodule-dld.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Since the initial addition of BeOS support in 1999, there has only
been one update to it (in 2005, and it wasn't even very big). GLib is
known to not currently build on Haiku (or presumably actual BeOS)
without additional patching, and the fact that there isn't a single
G_OS_BEOS check in gio/ is suspicious.
Additionally, other than the GModule implementation, all of the
existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
(b) random minor POSIXy tweaks (include this header file rather than
that one, etc), suggesting that if we were going to support Haiku, it
would probably be simpler to treat it as a special kind of G_OS_UNIX
(as we do with Mac OS X) rather than as its own completely different
thing.
So, kill G_OS_BEOS.
https://bugzilla.gnome.org/show_bug.cgi?id=710519
Skip the tests on inf/nan strings for the gvariant and strfuncs tests, and
skip the hex strings for the strtod tests in strfuncs as they are C99
features that are not yet supported by Visual C++ (even 2013). Use a
definition for NAN and INFINITY (that is also used in PyGObject) as
atof("NaN") and atof("Infinity") simply returns 0.0 (which is not a NAN)
in Visual C++ to fix the tests running there.
Also adapt to the format of g_ascii_formatd() when dealing with 1e99.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Use a Windows-style .bat script for the test_spawn_script() test, at least
when the code is built with Visual C++ (due to differences in how scripts
are written for shells and Windows cmd.exe), and account for Windows-style
line endings for that test too.
Let the MinGW builds (which are normally done in an MSYS BASH-style shell) continue to use the
*NIX-style script for that test.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Remove the parts about storing up the fd's in a data structure, but call
close() on the fd's. However, retain the _get_osfhandle() check on the
fd's when we iterate through the fd's as on fd values in the iteration may
well be invalid fd's. As a result, the invalid parameter handler is still
needed for newer Microsoft CRTs (8.0/2005+) for _get_osfhandle() to
make sure that the program does not abort when we check the validity of
fd's to be closed in the loop[1].
[1]: http://msdn.microsoft.com/en-us/library/ks2530z6%28v=vs.80%29.aspx
...Under various compilers when !G_DISABLE_CHECKS. Previously, the
messages that are logged differ depending whether GLib was built with GCC
or not. To simplify test cases, make all builds use a single output format
for g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), and
g_return_val_if_reached(), by using the GCC-style format and replaceing
__PRETTY_FUNCTION__ with G_STRFUNC, so that it will work across various
compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Even though we can't always make no-leak guarantees when g_warning()
in this case we're testing this behavior in tests, and it would be
good to be able to valgrind this.
https://bugzilla.gnome.org/show_bug.cgi?id=711751
Properly unref a pair of GSources in the unix-fd mainloop test.
valgrind was reporting these as 'still reachable' before (possibly due
to some residual pointers somewhere in memory), but when running with
G_DEBUG=cleanup they were properly reported as leaked.
Instead of having lots of 'if NULL then allocate' code segments for the
global GRand instance, move it to a single getter function that everyone
calls.
We were using g_mutex_init() to initialise a pair of mutexes in static
storage, but we should only do that for mutexes that are part of
allocated structures.
Include unistd.h only when G_OS_UNIX is defined (or when G_OS_WIN32 is not
defined). This will avoid including unistd.h unconditionally and/or
unecessarily, which may cause problems in certain scenarios, such as when
building the tests on Visual C++, which does not come with a unistd.h and
MinGW, where unistd.h is essentially a wrapper for io.h and process.h.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
...and fix the test on non-English Windows, as gettext on Windows does
not honor LC_ALL = "C" (the default CRT behavior) but requires using
SetThreadLocale() to set the locale as it picks up the user's environment
and the thread's locale. Without doing so the g_format_size_for_display()
et al will display the translated message if the gettext translations have
been installed before, causing the test_format_size_for_display tests to
fail.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
g_source_add_child_source() releases the context lock before attaching
child_source to context. And this causes trouble if parent source is
blocked and g_main_dispatch() manages to lock the context mutex and call
unblock_source() before child_source gets attached to context.
To fix this we call g_source_attach_unlocked() before releasing the
context mutex.
https://bugzilla.gnome.org/show_bug.cgi?id=711064
G_STRFUNC was checking __STDC_VERSION__ against the wrong value
(though it didn't actually matter, since __STDC_VERSION__ wasn't
defined in C90, so the check still only matched C99 and above anyway).
Make sure that if we ignore a tag then we also clear the attributes that
we already collected so that they don't end up on the next unignored tag
opening.
Also add some extra brackets for clarity (it doesn't make any difference
-- I just think it reads nicer this way).
https://bugzilla.gnome.org/show_bug.cgi?id=665634
Add a flag to GMarkupParserFlags to ignore qualified tags (along with
their contents) and attributes.
This will provide a nice way for some of our parsers (GDBus
introspection, GSettings schema, etc) to ignore additional tags that
users have added to their files, under a different namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
The code for dealing with </foo> and the second half of <foo/> was
largely duplicated. We can share a lot of it by using a common
function.
This slightly changes the behaviour of the parser under error
circumstances: previously the parser would deal with '<foo/}' by first
issuing the end_element callback and then flagging the error due to the
unexpected character. Now we will flag the unexpected character error
first, skipping the callback.
This behaviour change required modifying the testsuite.
https://bugzilla.gnome.org/show_bug.cgi?id=665634
Debug messages are meant to give insight into how a process is
proceeding, and are unpredictable in nature. They also often have
line numbers in them.
This patch ignores debug messages in g_test_assert_expected_messages().
https://bugzilla.gnome.org/show_bug.cgi?id=710991
We've added a g_critical() on failure to remove sources, so make sure we
expect to see that (instead of failing the test due to the unexpected
message).
https://bugzilla.gnome.org/show_bug.cgi?id=710724
In the case that g_key_file_get_(u)int64 fails to parse the integer,
make sure we free the string before returning.
Reported by Andrew Stone <astonecc@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=710313
Currently g_mem_gc_friendly is declared in both gmem.h and glib-init.h
files, we will have reports on each unit that include these two files.
This patch removes the redundant declaration from glib-init.h
Since g_mem_gc_friendly is related to gmem.h and was first declared in
this header which also exports it via glib.h, then declare it in gmem.h
Other files already include gmem.h: garray.c and gslice.c, no need to
change anything.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
No need to include glib-init.h here. This was added by
commit 47444dacc0 but that commit did not make use of any its
exported symbols, so just remove it.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
g_init_user_config_dir() is already declared as static in this gutils.c
file, so just remove the redundant declaration.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
_g_charset_get_aliases() is already declared in gcharsetprivate.h
which was added by commit 4c2a659588, and gconvert.c includes
this gcharsetprivate header, so no need to declare it again.
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
https://bugzilla.gnome.org/show_bug.cgi?id=710345
Passing a NULL value to g_setenv() was never documented as working,
and in fact it worked on some platforms and crashed on others. Make it
g_return_if_fail() everywhere insted.
Also, remove some incorrect docs in g_environ_getenv() and
g_environ_setenv() that shouldn't have been copied from g_getenv() and
g_setenv(). And belatedly simplify the checks in g_unsetenv().
https://bugzilla.gnome.org/show_bug.cgi?id=704593
Add a pair of functions to make it easier to do simple string matching.
This will be useful for use with things like GtkSearchBar and will also
be the basis of the searching done by the (soon to appear)
g_desktop_app_info_search()
https://bugzilla.gnome.org/show_bug.cgi?id=709753
When the source id reaches G_MAXUINT (just prior to overflow), we
record the existing source ids to prevent reassigning them. As we are
about to assign G_MAXUINT to the triggering source, that id should be
added as well.
https://bugzilla.gnome.org/show_bug.cgi?id=710002
This stack exists only to answer the question of "what is the currently
dispatching source" and is handled in a way that makes it very clear
that we don't need to be using a linked list at all...
Just store the GSource directly.
Independently discovered (and same solution) by Phillip Susi.
https://bugzilla.gnome.org/show_bug.cgi?id=709113
Add a simple UNIX-only API that is used to create a GDir object from a
DIR* that is aquired using opendir() or fdopendir().
This makes it possible to use GDir with openat(), which in turn will
allow use of GDir in the existing GLocalFile implementation of
g_file_measure_disk_usage(), avoiding the current MSVC compatibility
problems there.
Also add an API similar to g_dir_open(), but without the GError handling
(since we want to create a better error message from inside of
glocalfile.c).
Thanks to Chun-wei Fan <fanchunwei@src.gnome.org> for portions of this
patch and for reviews.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
We're testing for particular error messages, so we need to set to a C
locale to make sure we get the untranslated version.
Previously, this test set the LANG environment variable, but that's not
good enough if LANGUAGE is also set. The only way to ensure that
LANGUAGE is ignored is to disable l10n with LC_ALL=C.
Allow passing a NULL domain to g_test_expect_message(), and more
importantly, don't crash if a message with a NULL domain gets logged
while there is an expected message.
Implement gnulib strftime extensions for the '%z' numeric timezone
format. These are also supported and documented by GNU date(1):
%z +hhmm numeric time zone (e.g., -0400)
%:z +hh:mm numeric time zone (e.g., -04:00)
%::z +hh:mm:ss numeric time zone (e.g., -04:00:00)
%:::z numeric time zone with : to necessary precision (e.g., -04, +05:30)
https://bugzilla.gnome.org/show_bug.cgi?id=707151
Convert {glib,gobject,gio}/tests to use the automake TAP driver
and test harness instead of gtester. To do so, we add a glib-tap.mk
that provides the same interface as glib.mk, except for the
reporting and coverage testing functionality. Eventually, we may
want to replace glib.mk with it. I've not yet converted the
toplevel tests/ directory, since it mixes gtestutils tests with
other binaries.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
When using test harnesses other than gtester (e.g. using TAP),
it can be suboptimal to have the very first failed assertion
abort the test suite.
This commit adds a g_test_set_nonfatal_assertions() that can
be called in a test binary to change the behaviour of most
assert macros to just call g_test_fail() and continue. We
don't change the behavior of g_assert() and g_assert_not_reached(),
since these to assertion macros are older than GTest, are
widely used outside of testsuites, and will cause compiler
warnings if they loose their noreturn annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
These are just like g_assert(), but using a different entry
point for the message, so we can repurpose them together
with the other assertion macros.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
These two assertion macros are commonly used outside tests,
so we can't repurpose them, as we are going to do with the
other assertion macros in the following commits. This
change is in preparation for that.
https://bugzilla.gnome.org/show_bug.cgi?id=692125
This line was apparently causing build problems on Win64,
and since the only test involving the t_str variable was
already commented out, lets just take this out altogether.
https://bugzilla.gnome.org/show_bug.cgi?id=696970
The clang code analyzer needs to know that functions like g_error
g_critical an g_return_if_fail should be seen by the analyzer in the
same way as g_assert(). That is the analyzer should think they are
fatal.
https://bugzilla.gnome.org/show_bug.cgi?id=700268
The documentation for this function explicitly gives valid
ranges for the arguments and states that out-of-range arguments
will cause NULL to be returned. Only, the code didn't check
the ranges, and crashed instead. Fix that and add a testcase
for invalid arguments. It turns out that the test_z testcase
was providing invalid arguments and relied on g_date_time_new
to return a non-NULL value anyway, so this commit fixes that
testcase as well.
https://bugzilla.gnome.org/show_bug.cgi?id=702674
Put __glib_assert_msg in the dynamic symbol table, but not in any public
headers.
This variable is _not_ part of our API but this way debuggers and
automated crash report utilities will be able to access this variable,
even if debug symbols are not available.
https://bugzilla.gnome.org/show_bug.cgi?id=701800
Fix the warnings when compiling and linking the probes files by
calling dtrace with all the -W flags removed from CFLAGS (since dtrace
generates bad C code), and with CC set to "libtool --mode=compile ..."
(so that it will output a proper .lo file and libtool won't warn when
linking it into the .la).
https://bugzilla.gnome.org/show_bug.cgi?id=693335
test_GDateTime_diff() checks that the span from 2009-01-01 to
2010-01-01 is exactly 365 * G_TIME_SPAN_DAY, but it does this using
local time, and so fails if you are in a timezone that is in the
southern hemisphere which only did DST during one of 2008-2009 and
2009-2010 (in which case the year will end up being one hour too long
or too short).
Switch the diff tests to use UTC time instead; there are plenty of
other local time tests already.
https://bugzilla.gnome.org/show_bug.cgi?id=701529
On UNIX, we should only ever be looking at TMPDIR.
On Windows, we should only ever look at TEMP.
Also, clean up the documentation to better describe what is actually
happening. The previous docs may have left someone confused about why
this function returns "/var/tmp" on Solaris, even with no TMPDIR set.
https://bugzilla.gnome.org/show_bug.cgi?id=705075
As Visual Studio 2008 and later have support for the __pragma keyword,
where the compiler pragmas can be used in a macro, we can support
G_GNUC_BEGIN_IGNORE_DEPRECATIONS and G_GNUC_END_IGNORE_DEPRECATIONS
for Visual Studio 2008 and later, so many deprecation (C4996) warnings
can be suppressed when using these compilers when we use these macros
in the code.
https://bugzilla.gnome.org/show_bug.cgi?id=704543
This was introduced for Solaris performance theoretically;
we have never been able to use it on Linux/glibc because
the UTF-16 BOM state isn't reset.
We have no data about Solaris performance; were some to
still exist, we could reintroduce the code with an explicit
check for Solaris, not a check for glibc.
https://bugzilla.gnome.org/show_bug.cgi?id=704999
The timeout-based tests could fail on slow or heavily-loaded machines.
Change them to use a counter-based "timeout" source rather than a
time-based one, so they no longer depend on wall time.
https://bugzilla.gnome.org/show_bug.cgi?id=700460
On a heavily loaded system, it's possible that both our normal
condition *and* the timeout occurred. In that case we can just ignore
the timeout.
While I did add a "sig_timeout" boolean, we don't need to add any
assertions around whether or not it was reached - the assertions
covering the non-timeout case are sufficient. The sig_timeout boolean
is mainly for later debugging.
https://bugzilla.gnome.org/show_bug.cgi?id=700460
If someone creates a unix signal source for e.g. SIGINT, and then
removes it, reset the handler to SIG_DFL.
Not doing this was the source of race conditions in the
glib/tests/unix test, but this will also just make us a "good citizen"
by cleaning up.
For example, if a project temporarily creates a handler for SIGTERM,
and then later removes it, they almost certainly want SIGTERM to
revert to the default of terminating the process, rather than doing
nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=704699
The restrictions on partial matching no longer apply with PCRE >= 8.00.
The pcrepartial manpage contains the "FORMERLY RESTRICTED PATTERNS"
section:
"For releases of PCRE prior to 8.00, because of the way certain
internal optimizations were implemented in the pcre_exec() function, the
PCRE_PARTIAL option (predecessor of PCRE_PARTIAL_SOFT) could not be used
with all patterns. From release 8.00 onwards, the restrictions no
longer apply, and partial matching with can be requested for any
pattern."
https://bugzilla.gnome.org/show_bug.cgi?id=704250
- Mention G_SOURCE_CONTINUE and G_SOURCE_REMOVE in the GSourceFunc doc;
- Mention G_PARAM_READWRITE and G_PARAM_STATIC_STRINGS in the
GParamFlags doc;
- Fix "Since:" version for G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE;
- Fix typo.
https://bugzilla.gnome.org/show_bug.cgi?id=704250
We can't reset the pending flag for a signal until we've traversed
the whole list, as the documentation clearly says that in case multiple
sources they all get invoked.
This is still racy if you get a signal after checking the flag
but before resetting it, but it was the same before. The correct
fix would be to use sigwait() or signalfd(), but that would mean
blocking all signals in all threads, which is not compatible
with existing applications.
https://bugzilla.gnome.org/show_bug.cgi?id=704322
As the comment says, we may be delayed an arbitrary amount of time on
non-idle systems; update the assertions to reflect this.
This should fix periodic failures in the gnome-ostree continuous
integration system.
https://bugzilla.gnome.org/700460
For some time, the desktop file specification has supported "additional
application actions". This is intended to allow for additional methods
of starting an app, such as a mail client having a "Compose New Message"
action that brings up the compose window instead of the folder list.
This patch adds support for this with a relatively minimal API.
In the case that the application is a GApplication and DBusActivatable,
desktop actions are translated into GActions that have been added to the
application with g_action_map_add_action(). This more or less closes
the loop on being able to activate an application with an action
invocation (instead of 'activate').
https://bugzilla.gnome.org/show_bug.cgi?id=664444
Fix some leaks that turned up while valgrinding the GVariant testcase.
These leaks are small and only occur when there is already an error in
the program: they are leaks of temp strings used when formatting a
critical message.
These show up as leaks again the testcase under the new "expect
messages" approach. Previously, we fork()ed and these caused the
subprocess to abort, which is why this was not noticed before.
Otherwise we have to rely on pthread_cond_timedwait() actually using
the monotonic clock, which might be true or not. On Android at least
it is using the realtime clock, no pthread_condattr_setclock() is available
but instead pthread_cond_timedwait_monotonic() can be used.
This reverts commits dfbac178bd and
56348210f3.
These two commits introduce undesirable behaviour and were made with no
apparent approval from anybody at all, and without reference to a bug or
mailing list discussion.
Even when the app author specifies G_SPAWN_LEAVE_DESCRIPTORS_OPEN,
we should avoid leaking our internal pipe machinery into the
child.
Commit message written by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=703407
In order to fully undo the effects of g_mutex_init(),
it is necessary to reset the internal mutex pointer
back to NULL so that a later call to g_mutex_init()
actually works as expected.
Recent versions of clang have changed __PRETTY_FUNCTION__ to always
include the function signature (rather than including the function
signature in C++ but not in C like gcc does). This causes G_STRFUNC to
give different results under clang and gcc, causing some tests with
g_test_expect_messages() to fail.
Fix this by only using __PRETTY_FUNCTION__ in C++, and using
__FUNCTION__ in C. (Under gcc this change has no effect.)
https://bugzilla.gnome.org/show_bug.cgi?id=702147
When a child_source is added to a blocked source it has no context, yet we
call block_source on it that segfaults when it dereferences the NULL context
when it attempts to remove the file descriptors. To fix this we:
- Ensure that when we block a source, we don't attempt to remove its file
descriptors from a NULL context.
- Also ensure that when we attach a blocked source to a context, we don't add the
file descriptors to the context.
https://bugzilla.gnome.org/show_bug.cgi?id=701283
We didn't actually do any real-world testing of this, and
unsurprisingly it turns out to break in at least one widely-used
configuration (Fedora 19 x86_64, ext4 on LVM).
This reverts commit 9d0c17b501.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
ext3 and ext4 (for quite some time) with default mount options don't
need fsync() to ensure safety of replace-by-rename. Stop doing that for
these filesystems.
Note: this patch also impacts ext2, which is probably not safe, but I
don't know of any way to check ext2. vs the others because they all have
the same magic numbers (short of opening /proc/mount).
This patch assumes that if BTRFS_SUPER_MAGIC is defined then so will be
EXT3_SUPER_MAGIC.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Use a normal write() system call instead of fdopen() and fwrite().
This will definitely work on UNIX system and should work on Windows as
well...
As an added bonus, we can use g_close() now as well.
https://bugzilla.gnome.org/show_bug.cgi?id=701560
g_file_set_contents() sets a GError in the event of various failures
that count occur. It uses g_filename_display_name() in order to get the
filename to include in the messages.
Factor out the error handling to make it easier to allocate the display
name only when we need it (instead of allocating it every time).
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Extents-based filesystems like knowing in advance how much data will be
written to a file in order to prevent fragmentation. If we have it, use
posix_fallocate() before writing data in g_file_set_contents().
https://bugzilla.gnome.org/show_bug.cgi?id=701560
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
This should be the last users that need to be ported.
For some of the oldschool non-gtester-ified tests, we call g_test_init()
from main() because it is necessary in order to use
g_test_build_filename().
Since this feature is so utterly automake-centric, we may as well be
using the same terminology as automake itself (ie: although it's
BUILT_SOURCES, it's DIST_EXTRA, not DISTED).
Also add some comments to the enum explaining that these terms are
really corresponding directly to the automake terms.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Add a pair of functions for returning strings that don't need to be
freed. This is a bit of a hack but it will turn the 99% case of using
these functions from:
gchar *tmp;
tmp = g_test_build_filename (...);
fd = open (tmp, ...);
g_free (tmp);
to:
fd = open (g_test_get_filename (...), ...);
which is a pretty substantial win.
https://bugzilla.gnome.org/show_bug.cgi?id=549783
Windows doesn't define STDOUT_FILENO and STDERR_FILENO, and they're
not even guaranteed to be 1 and 2. So just use stdio instead. Also fix
a counting error. Pointed out on gtk-devel-list.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
Since we expect them to crash, let's not spam the system
core dump collection (systemd, abrt). At the moment
systemd is not very robust against programs crashing
in loops.
Instead of aborting, we exit(1).
https://bugzilla.gnome.org/show_bug.cgi?id=700714
See https://live.gnome.org/GnomeGoals/InstalledTests for more
information.
The tests now support being run both uninstalled and installed, so
'make check' works for those who want it. For tests which need data
files, the way this works is they look in the compiled in value of
SRCDIR by default, and the generated tests use "env G_TEST_DATA=" to
override that.
This patch only converts glib/tests for now; if this patch looks good,
I'll do the rest of the tests.
https://bugzilla.gnome.org/show_bug.cgi?id=699079
Rather than overloading --verbose, just skip the tests that aren't
supposed to be run in the parent process (so that if you do run the
toplevel test with --verbose, it doesn't immediately error out).
https://bugzilla.gnome.org/show_bug.cgi?id=679683
g_test_trap_fork() doesn't work on Windows and is potentially flaky on
unix anyway given the fork-but-don't-exec. Replace it with
g_test_trap_subprocess(), which re-spawns the same program with
arguments telling it to run a specific (otherwise-ignored) test case.
Make the existing g_test_trap_fork() unit tests be unix-only (they
never passed on Windows anyway), and add a parallel set of
g_test_trap_subprocess() tests.
Also fix the logic of gtestutils's "-p" argument (which is used by the
subprocess tests); previously if you had tests "/foo/bar" and
"/foo/bar/baz", and ran the test program with "-p /foo/bar/baz", it
would run "/foo/bar" too. Fix that and add tests.
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Not sure why it was doing this, but it's not necessary (all of glib's
tests pass fine without it), and it breaks tests that try to use
g_spawn_sync() or GChildWatchSource after doing a g_test_trap_fork().
https://bugzilla.gnome.org/show_bug.cgi?id=679683
Ryan accidentally committed some debugging code a long time ago,
causing this file to always use futex emulation even when real futex
support was available. I noticed this a while later and pointed it out
to him, and assumed he was going to fix it, but I guess he assumed I
was going to fix it, and then neither of us did...
https://bugzilla.gnome.org/show_bug.cgi?id=699500
This ancient code was attempting to cope with (unknown) systems whose
malloc() prototype was incompatible with the standard. This test was
fragile; it would break if the build environment provided -Wall in
CFLAGS.
Now that it's 2013, let's assume that target systems have a sane
malloc(). If someone complains, we can revisit this.
https://bugzilla.gnome.org/698716
This partially reverts commit ce0022933c.
It used to be safe to use g_spawn_sync() from processes that had their
own SIGCHLD handler because it simply called wait(). When it was
changed to depend on the GLib child watching infrastructure this meant
that GLib had to own the SIGCHLD handler.
This caused hangs in at least Pidgin.
The patch contained two other improvements to the child watch code which
we want to keep, so only revert the changes to gspawn itself.
https://bugzilla.gnome.org/show_bug.cgi?id=698081
All experienced GLib hackers know that G_SLICE=always-malloc is
absolutely essential when valgrinding but many users of GLib don't know
about this and get hit pretty hard when valgrinding their programs.
When initialising gslice, add a check to see if we are running under
valgrind and disable ourselves if we are.
We only do the check in the case that G_SLICE= was not specified in the
environment, so setting it to an empty string will prevent this default
behaviour.
I considered modifying gslice to use the VALGRIND_MALLOCLIKE_BLOCK
client request in all cases in order to just mark the blocks properly
but these calls are not free and gslice is pretty hyper-optimised. It's
easier to just disable gslice completely and this way we only have to do
one check during startup. It's also theoretically possible that someone
might want to use valgrind to debug gslice, in which case the extra
annotations would probably cause quite a lot of difficulty.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
This is a BSD-licenced header file that is designed to be copy-pasted
into programs. It will allow us to detect if we are running under
Valgrind and send "client requests" to it.
We will use this for a couple of reasons in upcoming patches.
https://bugzilla.gnome.org/show_bug.cgi?id=698595
Lots of people have variously asked for APIs like
g_variant_new_string_printf() in order to avoid having to use
g_strdup_printf(), create a GVariant using g_variant_new_string(), then
free the temporary string.
Instead of supporting that, plus a million other potential cases,
introduce g_variant_new_take_string() as a compromise.
It's not possible to write:
v = g_variant_new_take_string (g_strdup_printf (....));
to get the desired result and avoid the extra copies. In addition, it
works with many other functions.
https://bugzilla.gnome.org/show_bug.cgi?id=698455
Parsing wrongly-typed GVariant text format data is a well-defined
operation and it ought to result in a GError. We do that for most
cases, but 'v' and 'ay' were being treated differently. Fix those as
well.
set/endpwent are only required for iterating through passwd entries
using getpwent(). Since we are explicitly requesting a passwd entry
for a uid then the set/endpwent calls are redundant.
Removing these redundant calls is required for building on Android
since their C library doesn't implement these.
https://bugzilla.gnome.org/show_bug.cgi?id=645881
When unreffing a context with sources still attached, it would end up
unlocking an already-unlocked context, causing crashes on platforms
that (unlike Linux) actually check for that.
https://bugzilla.gnome.org/show_bug.cgi?id=697595
RHEL6 ships with GCC 4.4 by default, which doesn't understand the
nicer deprecated attribute that takes a message. However, we can at
least fall back to the old G_DEPRECATED, rather than silently doing
nothing.
This gives me warning messages when building OSTree on RHEL6 when I
accidentally added a usage of g_unix_fd_source_new().
https://bugzilla.gnome.org/show_bug.cgi?id=697160
Like all macros, we need to parenthesize arguments to ensure the order
of operations is correct.
See the mail thread starting at
<http://lists.fedoraproject.org/pipermail/devel/2013-March/180302.html>
"GCC produced wrong code in gvfs-1.14.2-3.fc18.x86_64" for how this
caused trouble with GVFS (which in turn caused trouble with
LibreOffice, where running "soffice sftp://.../.../test.odt" to access
an .odt file via GVFS failed to properly type-detect that file as a
Writer document and produced bogus error messages about the file being
broken).
https://bugzilla.gnome.org/show_bug.cgi?id=695925
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
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.
