Modify

Opened 9 years ago

Closed 8 years ago

#1519 closed Bug (Fixed)

Number conversion routines are inconsistent

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

Description

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.

Attachments (0)

Change History (6)

comment:1 Changed 9 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:

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.).

comment:2 Changed 9 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)

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.

comment:3 Changed 9 years ago by Jpm

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

comment:4 Changed 9 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.

Example:

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

Result: number:-2147483648

This is replicable in legit. pointers as well.

comment:5 Changed 9 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 8 years ago by trancexx

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

Fixed by revision [6308] in version: 3.3.7.20

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

Action
as closed The owner will remain trancexx.
Author


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

 
Note: See TracTickets for help on using tickets.