On 07/05/2017 02:04 PM, Max Reitz wrote: > Add a new test file (check-qobject.c) for unit tests that concern > QObjects as a whole. > > Its only purpose for now is to test the qobject_is_equal() function. > > Signed-off-by: Max Reitz <mre...@redhat.com> > --- > tests/Makefile.include | 4 +- > qobject/qnum.c | 16 +- > tests/check-qobject.c | 404 > +++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 417 insertions(+), 7 deletions(-) > create mode 100644 tests/check-qobject.c >
> +++ b/qobject/qnum.c > @@ -217,12 +217,16 @@ QNum *qobject_to_qnum(const QObject *obj) > /** > * qnum_is_equal(): Test whether the two QNums are equal > * > - * Negative integers are never considered equal to unsigned integers. > - * Doubles are only considered equal to integers if their fractional > - * part is zero and their integral part is exactly equal to the > - * integer. Because doubles have limited precision, there are > - * therefore integers which do not have an equal double (e.g. > - * INT64_MAX). > + * This comparison is done independently of the internal > + * representation. Any two numbers are considered equal if they are > + * mathmatically equal, that means: s/mathmatically/mathematically/ > + * - Negative integers are never considered equal to unsigned > + * integers. > + * - Floating point values are only considered equal to integers if > + * their fractional part is zero and their integral part is exactly > + * equal to the integer. Because doubles have limited precision, > + * there are therefore integers which do not have an equal floating > + * point value (e.g. INT64_MAX). > */ > +static void qobject_is_equal_num_test(void) > +{ > + QNum *u0, *i0, *d0, *d0p25, *dnan, *um42, *im42, *dm42; Given my comments on 2/5, do you want a dinf? > + QNum *umax, *imax, *umax_exact, *umax_exact_p1; > + QNum *dumax, *dimax, *dumax_exact, *dumax_exact_p1; > + QString *s0, *s_empty; > + QBool *bfalse; > + > + u0 = qnum_from_uint(0u); > + i0 = qnum_from_int(0); > + d0 = qnum_from_double(0.0); > + d0p25 = qnum_from_double(0.25); > + dnan = qnum_from_double(0.0 / 0.0); Are there compilers that complain if we open-code division by zero instead of using NAN from <math.h> (similarly, if you test infinity, I'd use the INFINITY macro instead of an open-coded computation) > + um42 = qnum_from_uint((uint64_t)-42); > + im42 = qnum_from_int(-42); > + dm42 = qnum_from_int(-42.0); > + > + /* 2^64 - 1: Not exactly representable as a double (needs 64 bits > + * of precision, but double only has 53). The double equivalent > + * may be either 2^64 or 2^64 - 2^11. */ > + umax = qnum_from_uint(UINT64_MAX); > + > + /* 2^63 - 1: Not exactly representable as a double (needs 63 bits > + * of precision, but double only has 53). The double equivalent > + * may be either 2^63 or 2^63 - 2^10. */ > + imax = qnum_from_int(INT64_MAX); > + /* 2^64 - 2^11: Exactly representable as a double (the least > + * significant 11 bits are set to 0, so we only need the 53 bits > + * of precision double offers). This is the maximum value which > + * is exactly representable both as a uint64_t and a double. */ > + umax_exact = qnum_from_uint(UINT64_MAX - 0x7ff); > + > + /* 2^64 - 2^11 + 1: Not exactly representable as a double (needs > + * 64 bits again), but whereas (double)UINT64_MAX may be rounded > + * up to 2^64, this will most likely be rounded down to > + * 2^64 - 2^11. */ > + umax_exact_p1 = qnum_from_uint(UINT64_MAX - 0x7ff + 1); Nice. > + > + dumax = qnum_from_double((double)qnum_get_uint(umax)); > + dimax = qnum_from_double((double)qnum_get_int(imax)); > + dumax_exact = qnum_from_double((double)qnum_get_uint(umax_exact)); > + dumax_exact_p1 = qnum_from_double((double)qnum_get_uint(umax_exact_p1)); Compiler-dependent what values (some) of these doubles hold. > + > + s0 = qstring_from_str("0"); > + s_empty = qstring_new(); > + bfalse = qbool_from_bool(false); > + > + /* The internal representation should not matter, as long as the > + * precision is sufficient */ > + test_equality(true, u0, i0, d0); > + > + /* No automatic type conversion */ > + test_equality(false, u0, s0, s_empty, bfalse, qnull(), NULL); > + test_equality(false, i0, s0, s_empty, bfalse, qnull(), NULL); > + test_equality(false, d0, s0, s_empty, bfalse, qnull(), NULL); > + > + /* Do not round */ > + test_equality(false, u0, d0p25); > + test_equality(false, i0, d0p25); > + > + /* Do not assume any object is equal to itself -- note however > + * that NaN cannot occur in a JSON object anyway. */ > + g_assert(qobject_is_equal(QOBJECT(dnan), QOBJECT(dnan)) == false); If you test infinity, that also cannot occur in JSON objects. > + > + /* No unsigned overflow */ > + test_equality(false, um42, im42); > + test_equality(false, um42, dm42); > + test_equality(true, im42, dm42); > + > + > + /* > + * Floating point values must match integers exactly to be > + * considered equal; it does not suffice that converting the > + * integer to a double yields the same value. > + * Each of the following four tests follows the same pattern: > + * 1. Check that both QNum objects compare unequal because they > + * are (mathematically). The third test is an exception, > + * because here they are indeed equal. > + * 2. Check that when converting the integer QNum to a double, > + * that value is equal to the double QNum. We can thus see > + * that the QNum comparison does not simply convert the > + * integer to a floating point value (in a potentially lossy > + * operation). > + * 3. Sanity checks: Check that the double QNum has the expected > + * value (which may be one of two in case it was rounded; the > + * exact result is then implementation-defined). > + * If there are multiple valid values, check that they are > + * distinct values when represented as double (just proving > + * that our assumptions about the precision of doubles are > + * correct). > + * > + * The first two tests are interesting because they may involve a > + * double value which is out of the uint64_t or int64_t range, > + * respectively (if it is rounded to 2^64 or 2^63 during > + * conversion). > + * > + * Since both are intended to involve rounding the value up during > + * conversion, we also have the fourth test which is indended to s/indended/intended/ > + * test behavior if the value was rounded down. This is the fourth > + * test. > + * > + * The third test simply proves that the value used in the fourth > + * test is indeed just one above a number that can be exactly > + * represented in a double. > + */ > + > + test_equality(false, umax, dumax); > + g_assert(qnum_get_double(umax) == qnum_get_double(dumax)); > + g_assert(qnum_get_double(dumax) == 0x1p64 || > + qnum_get_double(dumax) == 0x1p64 - 0x1p11); > + g_assert(0x1p64 != 0x1p64 - 0x1p11); > + > + test_equality(false, imax, dimax); > + g_assert(qnum_get_double(imax) == qnum_get_double(dimax)); > + g_assert(qnum_get_double(dimax) == 0x1p63 || > + qnum_get_double(dimax) == 0x1p63 - 0x1p10); > + g_assert(0x1p63 != 0x1p63 - 0x1p10); > + > + test_equality(true, umax_exact, dumax_exact); > + g_assert(qnum_get_double(umax_exact) == qnum_get_double(dumax_exact)); > + g_assert(qnum_get_double(dumax_exact) == 0x1p64 - 0x1p11); > + > + test_equality(false, umax_exact_p1, dumax_exact_p1); > + g_assert(qnum_get_double(umax_exact_p1) == > qnum_get_double(dumax_exact_p1)); > + g_assert(qnum_get_double(dumax_exact_p1) == 0x1p64 || > + qnum_get_double(dumax_exact_p1) == 0x1p64 - 0x1p11); > + g_assert(0x1p64 != 0x1p64 - 0x1p11); Okay, and you catered to the indeterminate nature of the compiler rounding pointed out earlier in the creation of the various doubles. So all-in-all, you may want to add tests for infinity (given the undefined nature of casting infinity to integer and any impact to commit 2/5), but what you have looks good: Reviewed-by: Eric Blake <ebl...@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature