gdb by default will only print strings up to 200 characters. After that
it abbreviates them. This affects the run-assert-msg-test.sh script if
the path to the glib installation is too long (in our case it was 133
characters, 132 would still have worked...)
By having gdb execute "set print elements 0" before printing the assert
string, the limit on maximum number of characters to print is set to
unlimited.
Signed-off-by: Peter Kjellerstedt <pkj@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=670218
And clarify the memory allocation requirement of the string arrays passed to
g_environ_{,un}setenv().
==9458== 10 bytes in 1 blocks are definitely lost in loss record 16 of 39
==9458== at 0x402AD89: malloc (vg_replace_malloc.c:236)
==9458== by 0x4221A1F: vasprintf (vasprintf.c:78)
==9458== by 0x40C6065: g_vasprintf (gprintf.c:314)
==9458== by 0x409D894: g_strdup_vprintf (gstrfuncs.c:509)
==9458== by 0x409D8C9: g_strdup_printf (gstrfuncs.c:535)
==9458== by 0x40672E9: g_environ_setenv (genviron.c:156)
==9458== by 0x80490E7: test_environ_array (environment.c:78)
==9458== by 0x40A3DB5: test_case_run (gtestutils.c:1662)
==9458== by 0x40A40B2: g_test_run_suite_internal (gtestutils.c:1715)
==9458== by 0x40A417C: g_test_run_suite_internal (gtestutils.c:1726)
==9458== by 0x40A42F9: g_test_run_suite (gtestutils.c:1771)
==9458== by 0x40A3441: g_test_run (gtestutils.c:1319)
==9458== by 0x80493F1: main (environment.c:108)
Bug #669412.
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
(array) without (element-type) means "array of the same type as
the C type", so gchar* with (array) is interpreted as an array of
strings. Since GKeyFiles must be UTF-8 encoded anyway, just
annotate it as a string.
https://bugzilla.gnome.org/show_bug.cgi?id=658484
Unix and Windows gio GSocket behaves differently when the socket is
closed by the peer. On Unix, the client receives pending data before
receiving HUP. But on Windows, the HUP may come before, resulting in
unreliable and racy code. We should have same behaviour on all
platforms.
According to MSDN documentation: "an application should check for
remaining data upon receipt of FD_CLOSE to avoid any possibility of
losing data."
https://bugzilla.gnome.org/show_bug.cgi?id=669810
When G_DISABLE_ASSERT is not defined, g_hash_table_foreach and
g_hash_table_find dereferences the hash table argument before
checking if it's NULL. This causes a crash when one of this function
is mistakenly called with a NULL argument instead of returning
with a warning through g_return_if_fail.
For a number of reasons it might be useful to register the object paths
associated with a non-unique application so that the application can at
least field requests to its unique D-Bus name.
https://bugzilla.gnome.org/show_bug.cgi?id=647986
g_file_read() was returning G_IO_ERROR_IS_DIRECTORY when you tried to
open a directory on unix, but G_IO_ERROR_PERMISSION_DENIED on win32.
Fix that, and add a test to tests/file.c
Pointed out on IRC by Paweł Forysiuk.
https://bugzilla.gnome.org/show_bug.cgi?id=669330
This is useful when using certain D-Bus services where the
PropertiesChanged signal does not include the property value such as
e.g. various systemd mechanisms, see e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=37632
Signed-off-by: David Zeuthen <davidz@redhat.com>
These tests were written, but then never used since it was decided to
add g_warnings() to goption.c in the cases they were supposed to be
testing. So anyway, just remove them.
This explains the current disabling of HAVE_IF_NAMETOINDEX as we are
still supporting Windows XP. This is expected to change when the patch
for XP support for if_nametoindex in accepted into master.
