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
