id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
1285	Unexpected result when using BitShift	ProgAndy	Valik	"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"	Bug	closed	3.3.1.6	AutoIt	3.3.1.5	None	Fixed