The test reveals that there's something fishy with this monitor.
One has to call g_app_info_get_all() for it to start working,
and then it only works once.
The static analyser (correctly) considers a type check to fail if the
variable is NULL. In this case, the address must be non-NULL as no error
was thrown by g_socket_connection_get_remote_address(), but the static
analyser doesn’t know this.
Add a non-NULL assertion anyway, both to shut the analyser up, and
because it’s good extra testing.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
These prevent some false positives from the static analyser which are
caused by it not inspecting the invariants of
g_subprocess_communicate[_utf8]_finish() (i.e. that stdout and
stdout_str will always be set unless an error was returned).
They’re also good testing anyway.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=113075
Be a little bit more careful in regards to initializing a primitive type
variable before passing it by reference, as it could have random stuff
in the variable's address depending on the CRT, such as MSVCR110.DLL,
causing random, invalid stuff being written in that address.
This will fix this test when built with Visual Studio 2012.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Make it possible to skip the terminal-launching test simply
by setting DISPLAY= . Previously, you had to unset DISPLAY,
which is a little more cumbersome.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
One testcase was launching appinfo-test from a GAppInfo that
does not have a filename. In this case, the G_LAUNCHED_DESKTOP_FILE
envvar is not exported. Make appinfo-test deal with that, without
spewing warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=711178
The actions test tests the GSimpleActionGroup API. Maybe this
should be moved to use GActionMap, but for now, just disable
the deprecations.
There was also one test that wasn't actually hooked up, so
do that as well.
Just copy the schemas to the builddir and compile them in place instead
of trying to mess around with creating the compiled file in a different
dir. This solves issues in the summary/description testcase when
GSettings expects the usual situation of having the .xml files present
in the same directory.
We need to check for the correct line endings on Windows (\r\n) for the
echo tests and currently need to skip the test_echo_eof test there, as
it depends on the cat utility that is not normally found on Windows, and
using an external installation of cat via MSYS or Cygwin would render the
test program to hang as cat waits for user input.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Various tests were depending on local_error being set by a callback
when it could never have been the case. Simplify async error detection
logic in those cases, and fix leak of GError.
https://bugzilla.gnome.org/show_bug.cgi?id=711802
We had a GApplication testcase that handled both open and commandline.
This only way that this worked was by implementing the commandline
handler without actually setting the HANDLES_COMMAND_LINE flag.
This behaviour is now invalid, so just rip out the offending part of the
test.
https://bugzilla.gnome.org/show_bug.cgi?id=711099
Include unistd.h only on *NIX and define items as necessary on Windows,
also replace instances of ssize_t with the GLib-equivilant gssize so to fix
the build on platforms that do not have ssize_t, such as Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
We need to use g_content_type_get_mime_type() to look up the mime type of
the file from the registry on the content type that was acquired on
Windows, as g_file_info_get_content_type() does not acquire the
file mime type (unlike on *NIX).
g_content_type_get_mime_type() on *NIX is more or less an no-op as it
simply returns the g_strdup()-ed version of the passed-in content type.
This will enable the resources test to pass on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
The overridden implementation of the skip method for
GLocalFileInputStream allows skipping past the end of the file which is
inconsistent with the documentation. Prevent this by first seeking to
the end of the file and then seeking backwards from there as much as
is necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=711048
If the goal is to make sure we don't have a dbus connection, it has
to call g_test_dbus_unset() instead which is much more complete.
In this case, g_test_dbus_unset() is called already, so it should be
fine.
https://bugzilla.gnome.org/show_bug.cgi?id=697348
This is to avoid having again the subtil bug in dbus-appinfo.c:
session_bus_down() was called before g_test_run() so the test was
running on the user's dbus session.
https://bugzilla.gnome.org/show_bug.cgi?id=697348
