Currently the docs for GChecksumType are simpy annotated
with 'Since 2.16' which is when GChecksumType was first
introduced. No mention is made of the fact that the
G_CHECKSUM_SHA512 constant was only added much later
in 2.36.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769027
GSettings objects were not unreffed in test_flags, test_enums and
test_ranges tests and when we skip internationalization tests, ie
test_l10n(_context).
https://bugzilla.gnome.org/show_bug.cgi?id=768560
OS X apparently stringifies the IPv6 address "::80" as "::0.0.0.128",
which is bizarre, but that address *is* in a "reserved for future use"
range, so it's not unambiguously wrong I guess. Anyway, fix the text
to use an address everyone can agree on.
https://bugzilla.gnome.org/show_bug.cgi?id=768551
The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool. In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.
The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.
Instead of trying to have dtrace run libtool we can have libtool run
dtrace. dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.
There appears to be some prior art for this approach. A quick search
shows that at least QEMU is using this approach. It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.
This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file. I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=725902
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
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
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
gcc 6 warns (fatally, by default) that %c only uses a 2-digit year
in some locales. The precise format does not seem to be important
for this sample code, so use ISO 8601 instead of suppressing the
warning with a pragma.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Colin Walters
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=768453
(cherry picked from commit 037719c27c)
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.
(cherry picked from commit 35b401c8bb)
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.
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.
Commit 99bdfd1b introduced a direct call to pthreads_setname_np in the
'thread' test case. Because we are directly calling pthreads functions
from this file now, we need to make sure we link it with the system
thread library flags (as we already do for another file).
https://bugzilla.gnome.org/show_bug.cgi?id=765712
Later Visual Studio versions does not allow one to define known keywords,
even if they are actually not known to the compiler. Avoid this issue by
checking more conditions before we define inline as __inline:
-We are not building under C++ mode.
-We are on Visual Studio 2013 or earlier.
Where both of these conditions need to hold true.
https://bugzilla.gnome.org/show_bug.cgi?id=765990
This reverts commit ca189aa321.
The new g_autoptr symbol definition in GDBus generated code breaks
existing code that uses gdbus-codegen and defines its own auto clean up
symbols.
This needs further discussion before cherry-picking to the stable
branch.
https://bugzilla.gnome.org/show_bug.cgi?id=763379
