Opened 14 years ago

Closed 13 years ago

#1519 closed Bug (Fixed)

Number conversion routines are inconsistent

Reported by: doudou Owned by: trancexx
Milestone: Component: AutoIt
Version: Severity: None
Keywords: number, conversion Cc:


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

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.

Attachments (0)

Change History (6)

comment:1 Changed 14 years ago by 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:


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

comment:2 Changed 14 years ago by 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)



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

comment:3 Changed 14 years ago by Jpm

  • Owner set to Jon
  • Status changed from new to assigned

comment:4 Changed 14 years ago by 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.



Result: number:-2147483648

This is replicable in legit. pointers as well.

comment:5 Changed 14 years ago by 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.

comment:6 Changed 13 years ago by trancexx

  • Milestone set to
  • Owner changed from Jon to trancexx
  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixed by revision [6308] in version:

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

as closed The owner will remain trancexx.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.