Two bugs for custom number types that compile on develop (found while
analysing #3578):
- compare_integer_with_float() took the signedness of the integer type
from std::is_signed, which is false for class types such as
absl::int128 or boost::multiprecision::cpp_int. Any float below zero
then compared less than every integer, e.g. json(int128(-5)) <
json(-2.5) was false. The signedness now comes from
std::numeric_limits, like the digits used for the range bound.
- With number_integer_t/number_unsigned_t wider than 64 bits (e.g.
__int128), CBOR, MessagePack, and BSON silently truncated integers
beyond 64 bits (to_cbor of 2^100 read back as 0), BJData truncated
unsigned ones with the 'M' marker and could encode truncated ND-array
elements and dimensions, and BON8 did not compile (std::to_string is
ambiguous for __int128). The writers now throw out_of_range.407 when
an integer does not fit the format's range ([-2^64, 2^64-1] for CBOR,
[-2^63, 2^64-1] for MessagePack, int64/uint64 for BSON, int64 for
BON8); BJData writes such unsigned values as high-precision numbers,
as it already did for signed ones and UBJSON does for both, and falls
back to a plain object for the ND-array. The checks use
std::numeric_limits digits and compile away when the number types are
at most 64 bits wide, so the default types pay nothing (the CBOR,
MessagePack, and BSON writers compile to identical code).
The new unit-custom-number-types.cpp tests the comparison with a small
class-type integer and the writers with __int128 where the standard
library supports it as an integral type.
Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Niels Lohmann
4001fe68b9