fix: add safe integer conversion for bitwise operations

[thevilledev]

Implements proper safety checks for all bitwise operations (<<, >>, &, ^, |, ~) when converting double values to int64_t. This prevents undefined behavior and potential security issues that could arise from integer overflow or the use of non-finite double values (NaN/Infinity) in bitwise contexts.

The implementation:

• Adds a safeDoubleToInt64 helper function with range validation.
• Applies this function consistently across all relevant bitwise operations in the interpreter.
• Limits values to the safe integer range [-2^53, 2^53] before conversion to int64_t.
• Includes an additional check to prevent left shift (<<) operations from causing int64_t overflow.
• Provides clear error messages, including source location context, when validation fails.

The safe integer range [-2^53, 2^53] is used because IEEE 754 double-precision floating-point numbers, as used by Jsonnet, can precisely represent all integers within this range. Using doubles outside this range for bitwise operations could lead to unpredictable results due to precision loss.

This change aligns with the Jsonnet specification, which requires bitwise operations to convert operands to signed 64-bit integers, while ensuring the conversion process is safe and mathematically sound within the limits of double precision representation. New test cases have been added to cover boundary conditions and potential errors.

NOTE: This was originally reported through the Google OSS VRP. Conclusion was that this can be reported publicly.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[thevilledev]

Unable to sign the CLA:

A server error occurred, please try your request again.

I will try later.

[thevilledev]

CLA signed.

[johnbartholomew]

Thanks for the contribution!

It would be good to have some basic test coverage of this.

[johnbartholomew]

I also wonder if we need to do something extra with left-shifts.

With the current code, 2^53 (or some other large value) can be left-shifted beyond the safe integer range. In fact this does work correctly up to a certain point because left shifting naturally gives a value which is a multiple of 2^x, and those values can be exactly represented even though adjacent integers cannot. However, since the operation is performed via a signed 64-bit integer, left shifting can easily result in undefined behaviour (pre C++20) or defined but confusing behaviour in C++20 and beyond.

See, for example, https://stackoverflow.com/a/60712725/52251

And this correct (perhaps) but rather confusing result:

$ ./jsonnet -e '4503599627370496 << 11'
-9223372036854775808

[thevilledev]

Good point! I added explicit checks before left-shifting to ensure the value won’t overflow a signed 64‑bit integer. If the shift would exceed 63 bits, we throw an error. This prevents undefined or confusing behavior and keeps left‑shifts within the safe range.

Tests are in and pass at least locally. Feedback welcome.

[johnbartholomew]

Thanks for continuing to work on this :-)

There is some inconsistency in the comments and code about whether the maximum safe value is 2^53 or (2^53)-1. It would be good to make sure this is correct and consistent in the comments and the actual logic.

2^53 can be represented exactly, so I would set that as the maximum (and correspondingly -2^53 as the minimum). This also matches the Jsonnet documentation.

https://en.wikipedia.org/wiki/Double-precision_floating-point_format#Precision_limitations_on_integer_values

(You can also verify it yourself by iterating through adjacent double-precision values, e.g., using nextafter, or by manually working out what the double precision representation is for 2^53-1 (ok), 2^53 (ok), and 2^53+1 (not representable!))

[thevilledev]

Thanks @johnbartholomew for the feedback! I guess I misunderstood the previous comment, but I've now aligned comments, code and tests to match what's in the Jsonnet spec.

[johnbartholomew]

Looks good! Would you mind rebasing onto master? Or I can do it when I merge.

[thevilledev]

Awesome! Rebase done