Re: [Qemu-block] [PATCH v4 5/5] tests: Add check-qobject for equality tests

[Eric Blake]

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 <address@hidden>
> ---
>  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 <address@hidden>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature