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
