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

[CertainLach]

@johnbartholomew

Missed that max integer value was reverted to 2**53 due to review.
I don't think that this is the correct behavior, and suggest reverting it to 2**53 - 1

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.

The problem here is that "safe" integer is the one that has defined successor and predecessor
2^53 does not have successor, thus arithmetic with it is already invalid, we can't distinguish between 2^53 and 2^53+1, thus we are not sure if the value we received from jsonnet code is valid

For example:

// 2^53 + 1 | 0 == 2^53
9007199254740993 | 0 == 9007199254740992

9007199254740993 is outside of safe integer range, but safe integer range check fails here, as the last bit of this number is already truncated on jsonnet number type side.

Only overflow with larger integer can be detected now

// 2^53 + 2
9007199254740994 | 0 // Error: lhs is outside of safe integer range