All work
Regression: BitXor,BitSHRN,BitSHLN return wrong answer when preciseMath is default and then toggled
Description
Environment
Attachments
relates to
Details
Details
Assignee
Reporter
Priority
MinorLabels
Fix versions
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Sprint
Activity
Pothys - MitrahSoft 17 December 2024 at 15:12
, I tested this ticket with Lucee version 6.2.0.218-SNAPSHOT. When I checked BitXor(), BitSHRN(), and BitSHLN() with the updated test cases. It returned the expected results and now its works fine.
Pothys - MitrahSoft 12 December 2024 at 08:13
, I have investigated this ticket using Lucee version 6.2.0.205-SNAPSHOT.
When I ran the test cases with "Precise Math" set to false in the admin panel, it returned an unexpected value.
The BitXor() function requires an integer value, but in this case, it is being used with a big integer.
Below is the test code for the BitXor() function with a big integer. It returns the expected value when "Precise Math" is set to false in the admin panel. However, the issue still occurs in the latest version.
Michael Offner 10 December 2024 at 09:19
improved test cases that failed. BitSHRN did start with a value that was outside of the range of double.
Michael Offner 10 December 2024 at 09:12
with BitSHLN.cfc you simply have an overflow of the double as you can see running this
i will adjust the test case
Michael Offner 9 December 2024 at 22:11
most likely this is because the value need to be converted from double to bigDecimal in this case and looses perciscion in the process, this is a edge case.
Found this while updating the tests to test both preciseMath true and false, toggling via the application tag
If preciseMath is enabled system wide, this works, if it’s disabled, it returns the wrong result?
with presideMath=true in the admin
but when false in the admin