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
The G_ADD_PRIVATE() macro, and the auto-generated get_instance_private()
internal function, should be used conditionally depending on the maximum
allowed version of GLib, as defined by the GLIB_VERSION_MAX_ALLOWED
pre-processor symbol.
This allows generating code that can be compiled in projects that wish
to use an older API version of GLib through the use of the
GLIB_VERSION_MAX_ALLOWED symbol.
https://bugzilla.gnome.org/show_bug.cgi?id=710133
This code was added for use by the G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID
file attribute, but may end up being used elsewhere (e.g. in GVfs) as well.
As it’s dealing with untrusted external files, and the non-trivial PNG file
format, this commit adds several test cases to cover valid and invalid PNG
files.
The security model for the thumbnail verification code is that the user’s
cache directory is untrusted, and potentially any PNG file which is passed
to the verifier has been manipulated arbitrarily by an attacker.
This is a follow-up to commit fe7069749f.
https://bugzilla.gnome.org/show_bug.cgi?id=709898
It is our intention that memory output streams should operate in two
distinct modes, depending on if a realloc function was provided or not.
In the case that we have a realloc function (resizable mode), we want
the stream to behave as if it were a file that started out empty. In
the case that we don't have a realloc function (fixed-sized mode), we
want the stream to behave as a block device would.
To this end, we introduce two changes in functionality:
- seeking to SEEK_END on a resizable stream will now seek to the end of
the valid data region, not to the end of the allocated memory (which
is really just an implementation detail)
- seeks past the end of the allocated memory size are now permitted,
but only on resizable streams. The next write will grow the buffer
(inserting zeros between).
Some tweaks to testcases were required in order not to break the build,
which indicates that this is an API break, but it seems unlikely that
anyone will be effected by these changes 'in the real world'.
Updates to documentation and further testcases are in following commits.
Based on a patch from Maciej Piechotka <uzytkownik2@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=684842
