Repository navigation
jsonnet's evaluateFile() silently messes up large integers #243
Description
For integer values on the boundary between signed and unsigned 64 bits values, the use of Jsonnet's evaluateFile silently (!!) changes the input values. It's not clear to me what is going on as the values aren't consistent, but all results end up even, so my guess it's truncation followed by expansion of some kind.
Examples: an input of a_uint: 18446744073709551615 becomes "a_uint": 18446744073709551616;"a_uint: 9223372036854775807" becomes "a_uint": 9223372036854775808; "a_uint: 922337203685477580" becomes "a_uint": 922337203685477632 after evaluateFile().
Note that direct use of boost::json doesn't show any issues and that this is internal to a jsonnet API, so not sure what to do with this bug report, but I'd figure I'd document it.
Activity
wlav commentedon Jan 8, 2026
Note that
18446744073709551104works fine, which is0b1111111111111111111111111111111111111111111111111111111000000000, giving credence to this being a truncation issue.wddgit commentedon Nov 4, 2026
Jsonnet has only one number type, a 64-bit IEEE 754 double. A double has 53 bits of precision, so it holds every integer exactly only up to 2⁵³ = 9,007,199,254,740,992 (about 9 × 10¹⁵).
wlav commentedon Nov 4, 2026
Yes, the reason is known and Beojan added a bug report on jsonnet forum. On our end, assuming it can't/won't be fixed, we should probably find a way to catch it: a 64 bit unsigned int being initialized to its max value is not something esoteric.