On 07/05/2017 12:04 PM, Max Reitz wrote: > Or, well, yes, it is in this case, but I meant literally UINT64_MAX + 1, > not the uint64_t value. I meant the natural number 2^64. > > Because the issue is that (double)UINT64_MAX will (or may, depending on > the environment and such) give us 2.0^64 == 0x1p64. > > And this is where the quotation I gave below comes in. When casting an > integer to a double we may end up with a value that is not representable > in the original integer type, so we cannot easily cast it back.
And it's more than just UINT64_MAX that rounds to the double value of 0x1p64. Okay, I'm starting to be convinced that using a floating-point comparison to 0x1p64 is going to be easier than an integer comparison to the rounding point (what point is that, anyways: where the low-order 11 bits that don't fit in 53 bits of precision cause us to round up instead of down?) >>> Justifying the use of binary exponents is going to be harder than that, >>> and would need a really good comment in the code, compared to just using >>> a safe double-cast. >> >> It's not safe. >> >> Max >> > > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
