jsonnet's evaluateFile() silently messes up large integers

[wlav]

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.

[wlav]

Note that 18446744073709551104 works fine, which is 0b1111111111111111111111111111111111111111111111111111111000000000, giving credence to this being a truncation issue.