summaryrefslogtreecommitdiff
path: root/tests
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2023-05-08 19:46:31 -0500
committerEric Blake <eblake@redhat.com>2023-05-09 08:28:09 -0500
commit2ab2ce57e665d77932348b6489836e5c31e9896b (patch)
treef30d05138da8c39e395cc880c1411141a28dfa35 /tests
parent1461c29301e95042268abca0c6e315d27500b948 (diff)
downloadglib-2ab2ce57e665d77932348b6489836e5c31e9896b.tar.gz
gtestutils: Improve g_assert_cmpuint
While x86_64 has enough precision in long double to do a round trip from guint64 to long double and back, this is platform-specific, and is a disservice to users trying to debug failing unit tests on other architectures where it loses precision for g_assert_cmp{int,uint,hex}. See also https://bugzilla.gnome.org/show_bug.cgi?id=788385 which mentions having to add casts to specifically silence the compiler on platforms where the precision loss occurs. Meanwhile, g_assert_cmpuint() does an unsigned comparison, but outputs signed values if the comparison fails, which is confusing. Fix both issues by introducing a new g_assertion_message_cmpint() function with a new 'u' numtype. For backwards compatibility, the macros still call into the older g_assertion_message_cmpnum() when not targetting 2.78, and that function still works when passed 'i' and 'x' types even though code compiled for 2.78 and later will never invoke it with numtype anything other than 'f'. Note that g_assert_cmpmem can also take advantage of the new code, even though in practice, comparison between two size_t values representing array lengths that can actually be compiled is unlikely to have ever hit the precision loss. The macros in signals.c test code does not have to worry about versioning, since it is not part of the glib library proper. Closes #2997 Signed-off-by: Eric Blake <eblake@redhat.com>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions