It’s hard to know whether trying to load a non-existent key file will
result in G_KEY_FILE_ERROR_NOT_FOUND or G_FILE_ERROR_NOENT; try to
improve the documentation to clarify that.
https://bugzilla.gnome.org/show_bug.cgi?id=777135
Clarify that g_key_file_get_integer() and g_key_file_get_integer_list()
both return G_KEY_FILE_ERROR_INVALID_VALUE if used to load a valid
integer which is out of range for a gint.
Don't refer to g_mkdtemp() when documenting g_mkdtemp_full() and
speaking about the function itself, and remove mention of flags in
aforementioned g_mkdtemp_full(), as it doesn't have such an argument
(but g_mkstemp_full() does).
https://bugzilla.gnome.org/show_bug.cgi?id=777493
If the match_info out argument is NULL, info will be freed, but then its
matches member will be accessed.
Spotted by Leslie Zhai <xiangzhai83@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=777077
This is small enough that it shouldn't cause problems on most machines
we support, but big enough to increase throughput on a lot of devices
and network protocols.
Note that the actual value is 256k minus malloc overhead, so that it
fits nicely in a 256k block (as suggested by Alexander Larsson).
See https://bugzilla.gnome.org/show_bug.cgi?id=773632https://bugzilla.gnome.org/show_bug.cgi?id=773823
It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
Mention that the *.headers are needed only if headers need to be installed
with the project/module after the build. Also, use a generic "YourProject"
rather than the "gdk-4" project file name--I missed changing the name in the
process.
The macros differ in their handling of NULL values — some macros ignore
them and pass through (e.g. G_TYPE_CHECK_INSTANCE_CAST) while others
will explicitly emit a warning if passed NULL (e.g.
G_TYPE_CHECK_INSTANCE).
Document their behaviour, so people don’t end up putting unnecessary
NULL checks in their code when doing checked type casts.
https://bugzilla.gnome.org/show_bug.cgi?id=735731
When performing the verify and building the error string there were two
possibilities of an infinite loop. The first is the missing twos-complement
to unset the bit in the filtered flags. The second is the lack of handling
G_SUBPROCESS_FLAGS_NONE which can return a valid GFlagsValue (and cannot
unset the bit since the value is zero).
This walks all known values in the GSubprocessFlags type class and check
if they are set. This has the benefit that we don't call needless functions
which walk the same table as well as avoiding mutating values to build
the error string.
https://bugzilla.gnome.org/show_bug.cgi?id=775913
When an invalid hostname is passed for connection, the
g_hostname_to_ascii() might fail when creating the request in
create_request(). Make sure that error is caught and reported rather
than passing "(null)" as the hostname of the site we want to connect to.
https://bugzilla.gnome.org/show_bug.cgi?id=772989
We kept seeing the glib testsuite hanging on our CI system in the
testcase for 642026. After some digging it turned out the jenkins slave
was misconfigured and its task limit was too low.
Add an assertion that the test thread has been created to more easily
spot this error condition as opposed to the test simply hanging.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=769672
The tests defaultvalue, gdbus-peer and gdbus-unix-addresses will fail
without DBUS, so only run them in case we HAVE_DBUS_DAEMON.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
https://bugzilla.gnome.org/show_bug.cgi?id=767609
When we make Visual Studio 2013 the baseline Visual Studio version, we need to
the *.vs12.sourcefiles that are generated along the way so that 'make distcheck'
won't complain about the leftover files. This was not caught in GLib as we do
not yet require Visual Studio 2013, but we update this here as this module is
intended to be used in projects that support Visual Studio project builds.
... when tty terminal emulators (such as mintty) are used. This support
is however for Vista and later, so use of such terminals should have
support for ANSI color codes in their outputs, even on Windows 7/8/8.1/
https://bugzilla.gnome.org/show_bug.cgi?id=775468
