pif_LongInt

by Popisfizzy
Double, triple, and quadruple-precision integers, both signed and unsigned.

When performing a right bitshift on negative integers, the sign bit is not preserved.

ID:2329483
 
Dec 19 2017, 10:37 pm (Edited on Dec 19 2017, 11:44 pm)
Resolved
Negative integers will now fill with 1's in the leading bits when bitshifting right. The BitshiftRightRotate() method is unaffected by this change.
BYOND Version:511
Operating System:Windows 10 Home 64-bit
Web Browser:Firefox 57.0
Applies to:DM Language
Status: Resolved (b1.2.2.20171227)
This issue has been resolved.
Descriptive Problem Summary:
When performing a right bitshift on negative integers (i.e., of the Signed32 class), the sign bit is not preserved. E.g., 0x80000000 >> 1 = 0x40000000 instead of 0xC0000000 as expected.

Code Snippet (if applicable) to Reproduce Problem:
var/pif_LongInt/Signed32/A = new("0x8000000")
A >>= 1
world << A.PrintHex()


Expected Results:
0xC0000000 is output.

Actual Results:
0x40000000 is output.
Dec 20 2017, 1:02 am (Edited on Dec 20 2017, 10:37 am)
Technically this isn't a bug, but usually a >> 1 is numerically the same as integer division by 2, and the choice of filling it leading 1's on a negative signed integer preserves this behavior. As such, it's common behavior and my library is non-conforming to that behavior.

I'm leaving it as a Bug Report because it seems more appropriate than a Feature Request.
Dec 27 2017, 2:22 am
Popisfizzy resolved issue with message:
Negative integers will now fill with 1's in the leading bits when bitshifting right. The BitshiftRightRotate() method is unaffected by this change.