hex conversion

[memoryoverflow]

Rather than that I crashed I have been crashed - absolut care on my side, but no chance to react better in a time of 300-400 msecs.

And think twice whether to prefer the virtual BSOD over the consequences of a real 3D crash.

[memoryoverflow]

Eventually, i.e. yesterday, I've had the opportunity for the test on that XP machine: ¹

Casting explicitely to integer gives same results on both computers.

Typing the pure number into SciTE gave varying results, which makes me mistrust the health of that XP machine (corrupted OS and/or intermittent HW defect?).

What I'm still uncertain about: What is the expected behaviour for a double > 2^32 ?

That of the 2k machine, i.e. Hex(<double>) seen as signed (negative) integer?

Or Hex(<double>) = 0x80000000 (which I rather perceive as an error code)?

<ot>

¹) the reason for the delay is the part you might find funny:

There had been a date for a meeting in that office on Monday, which I wanted to use for the test, too.

A phone call on Monday morning postponed that date, because my partner had a traffic accident on Sunday.

Not having my vehicle repaired yet, I avoid the now hours long way, as long as it's not vital to get there.

</ot>

Edited October 18, 2009 by memoryoverflow

[Inverted]

I noticed that in the latest beta, there were some changes in the Hex function. Maybe you should try to see if anything has changed ? Also, why hasn't a developer posted here yet to set things straight ?

Maybe you should open a ticket or something, since you can reproduce the different behaviour.

[TurionAltec]

This code:

Global $sKey = "HKCU\SOFTWARE\AutoIt v3"
RegWrite($sKey, "Test_DWORD", "REG_DWORD", 4294967295)
ConsoleWrite(Hex(RegRead ($sKey, "Test_DWORD"))&@CR)
ConsoleWrite(Hex(4294967295)&@CR)
$vRead = RegRead($sKey, "Test_DWORD") ; Type = Double
ConsoleWrite("$vRead = " & $vRead & "; Type = " & VarGetType($vRead) & @LF)
$vTest = 0xFFFFFFFF ; Type = INT32
ConsoleWrite("$vTest = " & $vTest & "; Type = " & VarGetType($vTest) & @LF)

On XP Pro-SP2 AutoIT 3.3.0.0

returns:

80000000
FFFFFFFF
$vRead = 4294967295; Type = Double
$vTest = -1; Type = Int32

XP Pro-SP3 AutoIT 3.3.0.0

FFFFFFFF
FFFFFFFF
$vRead = 4294967295; Type = Double
$vTest = -1; Type = Int32

EDIT: another XP pro-sp3 machine returns:

80000000
FFFFFFFF
$vRead = 4294967295; Type = Double
$vTest = -1; Type = Int32

Edited October 19, 2009 by TurionAltec

[memoryoverflow]

phew... especially your last 2 machines seem to answer it (and show that my surprise to observe this behaviour wasn't that surprising):

No unique respons to be expected (unless, perhaps, you know the processor and check for it before you use the function in a program).

Would that be considered a bug now?

[TurionAltec]

int(RegRead ($sKey, "Test_DWORD"))

Will return an Int64 (not Int32), but it will show up as "FFFFFFFF" on all systems.

As far as any difference in machine architecture:

All machines Running XP pro 32 bit. All machines report "Double" type returned from RegRead

FFFFFFFF - 32 bit Intel processor, "Advanced Configuration and Power Interface (ACPI)" HAL (older PIII based Celeron)

80000000 - 32 bit Intel processor, "ACPI Uniprocessor" (Celeron-M)

80000000 - 64 bit AMD Processor, "ACPI Multiprocessor" (Turion X2)

80000000 - 64 bit AMD Processor, "ACPI Uniprocessor" (Athlon 3800+)

I assume it may be due to processor features (SSE2, etc) and compiler optimizations, and not the HAL.

I tried compiling against the Beta, and it will default to a 16 character length:

00000000FFFFFFFF

on all systems tested, so there's no point reporting a bug as the whole Hex function has been revamped, and seems to show properly.

I can try testing against a couple PIIIs and a PII though I don't know what would be gained.

Edited October 19, 2009 by TurionAltec

[TurionAltec]

Try this:

Global $sKey = "HKCU\SOFTWARE\AutoIt v3"

RegWrite($sKey, "Test_DWORD", "REG_DWORD", 4294967295)
$Value = RegRead($sKey, "Test_DWORD")
$value2=BitAND($Value, 0xFFFFFFFF)
ConsoleWrite("$value = " & $Value & "; Type = " & VarGetType($Value) & " Hex = " & Hex($Value)&@CRLF)
ConsoleWrite("$value2 = " & $value2 & "; Type = " & VarGetType($value2) & " Hex = " & Hex($value2)& @CRLF)
If $Value=0xFFFFFFFF Then ConsoleWrite("Success Value"&@CRLF)
If $Value2=0xFFFFFFFF Then ConsoleWrite("Success Value2"&@CRLF)

$Value3 = int(RegRead($sKey, "Test_DWORD"))
$value4 = BitAND($Value3, 0xFFFFFFFF)
ConsoleWrite("$value3 = " & $Value3 & "; Type = " & VarGetType($Value3) & " Hex = " & Hex($Value3)&@CRLF)
ConsoleWrite("$value4 = " & $value4 & "; Type = " & VarGetType($value4) & " Hex = " & Hex($value4)& @CRLF)

If $Value3=0xFFFFFFFF Then ConsoleWrite("Success Value3"&@CRLF)
If $Value4=0xFFFFFFFF Then ConsoleWrite("Success Value4"&@CRLF)

All computer trigger in Case 4, and that single one from earlier triggered in case 2.

----------------------

I am playing with Hex() and Int64 in the Beta, and I'm getting:

7FFFFFFFFFFFFFFF=9223372036854775807

7FFFFFFFFFFFFFFF=-1

7FFFFFFFFFFFFFFF=9223272036854775806

7FFFA50CEF85BFFE=9223272036854775807

0x7FFFA50CEF85B000=7FFFA50CEF85BFFE=9223272036854771712

I shall stop playing with that which I don't understand!

Edited October 19, 2009 by TurionAltec

[Inverted]

So, the problem is with Hex function's handling of double precision numbers ?

Better open a ticket so it's fixed for the final stable version, with this info on your tests on the beta.

I don't understand enough to do it

[memoryoverflow]

Better open a ticket ... I don't understand enough to do it

hehee, what should I say?

My knowledge about it isn't much more than observing something I don't understand.

But if a developer stumbles over TA's tests - thanks for that! - he might know what to do.

(I tried to answer TA's posts earlier, but have been logged out every time I tried to post, as that other machine permantly seemed to 'forget' my password while I spent the days and the night in that other office.)