The condition removed erroneously excluded UTC-based and DST-less
timezones and so left the GArray with no contents, so GTimeZone functions
returned whatever random garbage was in memory.
If a backup file is created, opened successfully, then fstat() on it
fails (perhaps due to another process deleting it in the mean time?),
the FD will be leaked.
Coverity issue: #1159485https://bugzilla.gnome.org/show_bug.cgi?id=730187
Expand the set of available probes, and add a few more output parameters
to some of the existing ones to make them more useful. I do not know if
this breaks any existing stability guarantees for GLib’s SystemTap
tapset, as it is effectively just adding some more local variables in
the user’s probe.
https://bugzilla.gnome.org/show_bug.cgi?id=759813
Previously this would cause an assertion failure when checking the paths
of exported objects, as it would try to check that their paths started
with ‘//’ due to mishandling the root object case.
Includes a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=761810
proxy->priv->name_owner gets overwritten in async_init_data_set_name_owner() on the
assumption that it will always be NULL when we get there. However,
on_name_owner_changed() can run first, and it does set name_owner.
==20126== 42 bytes in 6 blocks are definitely lost in loss record 15,174 of 48,256
==20126== at 0x4C280F3: malloc (vg_replace_malloc.c:299)
==20126== by 0x7541D00: g_malloc (gmem.c:104)
==20126== by 0x7558FEE: g_strdup (gstrfuncs.c:364)
==20126== by 0x6DF8E4F: on_name_owner_changed (gdbusproxy.c:1399)
==20126== by 0x6DE94C4: emit_signal_instance_in_idle_cb (gdbusconnection.c:3743)
==20126== by 0x753C315: g_main_dispatch (gmain.c:3066)
==20126== by 0x753C315: g_main_context_dispatch (gmain.c:3642)
==20126== by 0x753C667: g_main_context_iterate.isra.24 (gmain.c:3713)
==20126== by 0x753CA69: g_main_loop_run (gmain.c:3907)
==20126== by 0x5E38000: meta_run (main.c:556)
==20126== by 0x401EC0: main (main.c:441)
https://bugzilla.gnome.org/show_bug.cgi?id=755439
Allow the use of shorthands using ${prefix} for exec_prefix, and
${exec_prefix} for includedir and libdir, which makes the generated .pc
files a bit cleaner and more flexible.
For the Visual Studio 201x projects, we can force the "install" projects
to always run in a simpler way, by specifying an output file that will
never exist. Makes things look a bit cleaner.
We may not have $(CopyDir) created, which the script that generates the
.pc files check for, so create it if it is not there. This makes things a
bit more convenient for people.
Visual Studio actually supports long long types, but HAVE_LONG_LONG is
undefined for Visual Studio builds, likely due to issues in previous
gnulib code for printf functionality, that was bundled with GLib.
Since gnulib has much better support with Visual Studio nowadays (which we
updated the related code to last October), and HAVE_LONG_LONG being undefined
actually causes issues in Visual Studio builds, which was demonstrated with
the type-test test program in tests/, we should always define HAVE_LONG_LONG
in config.h.win32.in.
Thanks to Paolo Borelli for the heads up on the issue.
Adds the filename annotation for all file names
and things which can contain file names like
environment variables, argv-
On Unix they can contain anything while on Windows
they are always utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=767245
This fixes a build failure in Continuous that resulted in the error:
../../../gio/tests/test.gresource.xml: Failed to locate
'test-generated.txt' in any source directory.
Makefile:4676: recipe for target 'test.gresource' failed
make[6]: *** [test.gresource] Error 1
Some compilers have trouble with such sequences. Visual C++ may or may
not generate a warning in this particular case depending on if the
local code page supports an ellipsis.
https://bugzilla.gnome.org/show_bug.cgi?id=767218
Visual Studio 2008 does not come with stdint.h, so define intmax_t instead
on Visual Studio 2008 so that the code will continue to build. This was
previously unnoticed as building GTK+ since 3.16 requires an
implementation of stdint.h (such as msinttypes), and it took care of the
need of including the stdint.h header here, but people could be very well
using GLib without using GTK+ 3.x.
glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.
This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`. This is due to a namespace clash.
One fix would be to rename the gdb helper files to not clash with
other Python modules. This should be done for all such helper files.
https://bugzilla.gnome.org/show_bug.cgi?id=760186
Nautilus wants to show entries in the sidebar only for removable devices.
It uses currently sort of conditions to determine which devices should be
shown. Those condition fails in some cases unfortunatelly. Lets provide
g_drive_is_removable() which uses udisks Removable property to determine
which devices should be shown. It should return true for all drives with
removable media, or flash media, or drives on usb and firewire buses.
https://bugzilla.gnome.org/show_bug.cgi?id=765900
Fallback code for g_date_time_format_locale() fetches translated
strings (such as day and month names) from .mo catalogues via
gettext. These strings always come in UTF-8 encoding, because
that is the encoding that glib sets when it initializes gettext
for itself.
However, the non-fallback code uses nl_langinfo() and expects
its results to be in locale-dependent encoding.
This mismatch can result in UTF-8 strings being converted to UTF-8,
producing gibberish.
Fix this by converting UTF-8 strings to locale-dependent encoding
before using them. Also fix the code that was already doing the locale->UTF-8
conversion to not convert the strings when they are already UTF-8-encoded.
https://bugzilla.gnome.org/show_bug.cgi?id=766092
This prevents testsuite from trying to build any TESTS in that
subdirectory, which will fail, because there are no TESTS defined
in that Makefile.am.
This happens when user runs make check TESTS=...
https://bugzilla.gnome.org/show_bug.cgi?id=766407
There is no need to call g_variant_builder_clear() after the
g_variant_builder_end(). This is mentioned in docs of the former
function, but not in the docs of the latter one. Add them there too.
Instead of finding the GSequence, just walk up
the tree and determine if the iter is the end node.
https://bugzilla.gnome.org/show_bug.cgi?id=749583
Signed-off-by: Garrett Regier <garrettregier@gmail.com>
