Unexpected result when using BitShift

[ProgAndy]

BitShift seems to return a wrong result if the input is a 64bit integer variable. In previous AutoIt versions it used to cut all numbers to 32bit, but now the 64-bit integer is shifted over the whole 64bit range, which leads to unexpected results.

;#BETA
$iNum1 = 4294967295
$iNum2 = 0xFFFFFFFF
$iNum3 = -1

MsgBox(0, 'Number tests', "$iNum1 = 4294967295 	-> " & $iNum1 & @CRLF & _
				"$iNum2 = 0xFFFFFFFF 	-> " & $iNum2 & @CRLF & _
				"$iNum3 = -1 		-> " & $iNum3 & @CRLF & @CRLF & _
				"$iNum1 = $iNum2 	-> " & ($iNum1 = $iNum2) & @CRLF & _
				"$iNum1 = $iNum3 	-> " & ($iNum1 = $iNum3) & @CRLF & _
				"$iNum3 = $iNum3 	-> " & ($iNum3 = $iNum3) & @CRLF & @CRLF & _
				"I expected $iNum1 and $iNum2 to be equal, since 0xFFFFFFFF is hex notation for 4294967295" _
				)

MsgBox(0, "+/- BitShift", "BitShift($iNum1, 16) -> " &  BitShift($iNum1, 16) & @CRLF & _ 
			"BitShift($iNum2, 16) -> " & BitShift($iNum2, 16) & @CRLF & _ 
			"BitShift($iNum3, 16) -> " & BitShift($iNum3, 16) & @CRLF & _
			"The BitShift for $iNum1 seems to be incorret." )

When declaring the variables for the example i noticed the different interpretation of 0xFFFFFFFF and its decimal representation (4294967295). I don't know if this is a bug and it exists in previous versions of AutoIt, too. 4294967295 is treated as a 64bit integer and keeps its positive value, whereas The Hex is treated as signed 32bit which results in -1. So the identical values can not be testet as equal

[ProgAndy]

Oh no, i ran my BitNot-Test with Stable. Now with Beta, the error occurs, too:

;#BETA
$iNum1 = 4294967295

MsgBox(0, '', BitNOT($iNum1))
MsgBox(0, '', BitNOT(BitNOT($iNum1)))

[Valik]

Fixed by revision [5372] in version: 3.3.1.6