On Tue, Nov 24, 2020 at 01:22:02PM +0100, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > > > On 24/11/20 10:55, Markus Armbruster wrote: > >>> + /* Larger than UINT64_MAX: */ > >>> + QLIT_QNUM_DOUBLE(18446744073709552e3), > >>> + /* Smaller than INT64_MIN: */ > >>> + QLIT_QNUM_DOUBLE(-92233720368547758e2), > >> Why "larger than UINT64_MAX" and "smaller than INT64_MIN"? > >> > > > > I guess the point is to test values that are only representable as a > > double, so (double)((uint64_t)INT64_MAX+1) wouldn't be very useful for > > that: as the expression shows, it would not be a QNUM_VAL_INT but it > > would be representable as QNUM_VAL_UINT. > > > > So these are the cases that matter the most, even though -1, 0 and > > INT64_MAX+1 could be nice to have. > > qnum_is_equal()'s contract: > > * Doubles are never considered equal to integers.
If that's part of the contract, it would be OK to include 0.0, -1.0, 1.0, INT64_MAX+1 in the list. I incorrectly assumed qnum_is_equal(qnum_from_int(0), qnum_from_double(0.0)) was undefined. However, if we really care about test coverage of qnum_is_equal(), we probably should be extending check-qnum.c, not check-qlit.c. -- Eduardo