Bug? Inconsistent handling of hex literals

[OliverA]

It looks like sometimes B4i will convert a hex string literal (in my case 0xC0000000) either into an Int or a Long. Currently I can create this phenomenon in debug mode (I've not had time to test in release mode). Here is the sub

private Sub hexliteral2
    Log("2")
    Log(MAX_32)
    
    Log(MIN_32)
    'Log(0x80000000)
    'Log(GetType(0xC0000000))
    Log(0xC0000000)
    Dim aInt As Int = 0xC0000000
    Log(aInt)
End Sub

This will result in

Application_Start
2
2147483647
-2147483648
-1073741824
-1073741824
Application_Active

If you comment the GetType out you'll get

Application_Start
2
2147483647
-2147483648
__NSCFNumber
3221225472
-1073741824
Application_Active

This inconsistency caused me to pull my hair out since I ran into some voice compression issues and I finally figured out it was due to this sub

Sub shiftLeft(var1 As Int, var2 As Short) As Int
    If var2 <= 0 Then
        Return shiftRight(var1, -var2)
    Else
        Do While var2 > 0
            If var1 > 0x3FFFFFFF Then
                Overflow = True
                var1 = LD8KShared.MAX_32
                Exit
            Else If var1 < 0xC0000000 Then
                Overflow = True
                var1 = LD8KShared.MIN_32
                Exit
            Else
                var1 = var1 * 2
                var2 = var2 - 1
            End If
        Loop
        Return var1
    End If
End Sub

Note: MAX_32 and MIN_32 are defined as 0x7fffffff and 0x80000000 respectively
When using this sub via

Dim tmp as Int
tmp = shiftLeft(0,3)
Log(tmp)

I expected 0, but got -2147483648 (MIN_32). What happened is that 0xC0000000 was treated as 3221225472 instead of -1073741824

Note: I'm pretty sure that the issue also exists in Release mode, since originally my project bombed out in a Release test under B4i. I at first assumed (wrongly) that it had something to do with bite order (I'm working with this library under B4A and B4J - where everything seems to work as expected), but it looks like it is a more nuanced issue.

 

[Erel]

1. There is indeed a bug here.
2. It treats the number as an unsigned int instead of a signed int (as in B4J and B4A).
3. It will be fixed.

 

[Erel]

The next version of B4A, B4J and B4i will support long hex literals as well as long bit methods.