Number conversion routines are inconsistent

[doudou]

I would expected the following code to produce (arithmetically) the same values:

ConsoleWrite("Converting pointer value " & Ptr(-1) & @LF)
ConsoleWrite("Number(ptr)=" & Number(Ptr(-1)) & @LF)
ConsoleWrite("Int(ptr)=" & Int(Ptr(-1)) & @LF)
ConsoleWrite("Number(string)=" & Number("" & Ptr(-1)) & @LF)
ConsoleWrite("Int(string)=" & Int("" & Ptr(-1)) & @LF)

The results are however:

Converting pointer value 0xFFFFFFFF
Number(ptr)=-1
Int(ptr)=0
Number(string)=4294967295
Int(string)=4294967295

We get 3 different numbers from the same input here: 2 signed integers of different! values and 1 unsigned. If a pointer internally is an unsigned int it should be handled by all conversion routines accordingly.

Int(0xFFFFFFFF) = 0 is in every case complete nonsense.

[doudou]

I can add a couple:

ConsoleWrite("Floor(ptr)=" & Floor(Ptr(-1)) & @LF)
ConsoleWrite("Ceiling(ptr)=" & Ceiling(Ptr(-1)) & @LF)
ConsoleWrite("Floor(string)=" & Floor("" & Ptr(-1)) & @LF)
ConsoleWrite("Ceiling(string)=" & Ceiling("" & Ptr(-1)) & @LF)

gives you:

Floor(ptr)=0
Ceiling(ptr)=0
Floor(string)=4294967295
Ceiling(string)=4294967295

Obviously all routines that explicitly produce an int are buggy (AutoIt 3.3.6.1 incl.).

[doudou]

Yet even more confus(ed)ing:

ConsoleWrite("Number(binary)=" & Number(Binary(Ptr(-1))) & @LF)
ConsoleWrite("Int(binary)=" & Int(Binary(Ptr(-1))) & @LF)
ConsoleWrite("Floor(binary)=" & Floor(Binary(Ptr(-1))) & @LF)
ConsoleWrite("Ceiling(binary)=" & Ceiling(Binary(Ptr(-1))) & @LF)

produces:

Number(binary)=4294967295
Int(binary)=-1
Floor(binary)=0
Ceiling(binary)=0

I stumbled upon these inconsistencies when I tried to port some C hashing routines to AutoIt and was confronted with quite unpredictable results.

[Ascend4nt]

To add to the other issues with Number(), it appears there is a 32-bit signed-integer limit in converting from pointers to numbers. I had to rely on this method in the past due to bad pointer comparisons in AutoIT.

Example:

$pPtr=Ptr(0x80000000)
ConsoleWrite("number:"&Number($pPtr)&@CRLF)

Result: number:-2147483648

This is replicable in legit. pointers as well.

[Ascend4nt]

I should mention that pointer arithmetic fails too because of the same limitation:

Number($pPtrA-$pPtrB) -> will give negative results if the 31st bit is set in the result of the subtraction.

[trancexx]

Fixed by revision [6308] in version: 3.3.7.20