Data type conversion in AutoIt v3.3.10.2

[asdf8]

Compared with the version 3.3.8.1 changes not in best side :

$t = DllStructCreate('uint')
DllStructSetData($t, 1, 22)
$var = DllStructGetData($t, 1)

ConsoleWrite('-> $var = ' & $var & @CRLF)
ConsoleWrite('-> Int($var) = ' & Int($var) & @CRLF)
ConsoleWrite('-> IsInt($var) = ' & IsInt($var) & @CRLF)
ConsoleWrite('-> IsInt(Int($var)) = ' & IsInt(Int($var)) & @CRLF)

$oD = ObjCreate("Scripting.Dictionary")
$oD.CompareMode = 1

For $i = 0 To 50
    $oD.Item(Int($i)) = $i
Next

ConsoleWrite('!>' & Int($oD.Exists(Int($var))) & @CRLF)

ConsoleWrite('!>' & Int($oD.Exists(22)) & @CRLF)
ConsoleWrite('!>' & Int($oD.Exists(Int($var, 1))) & @CRLF)

[Melba23]

asdf8,

To my simple mind your results seem entirely logical:

$oD.CompareMode = 1
For $i = 0 To 50
    $oD.Item(Int($i)) = $i
Next

$t1 = DllStructCreate("uint")
DllStructSetData($t1, 1, 22)
$var1 = DllStructGetData($t1, 1)
ConsoleWrite("UINT: " & Hex($var1) & @CRLF)

ConsoleWrite('!>' & Int($oD.Exists(22)) & @CRLF)
ConsoleWrite('!>' & Int($oD.Exists($var1)) & @CRLF) ; Does not work as uint size
ConsoleWrite('!>' & Int($oD.Exists(Int($var1))) & @CRLF) ; autosized - left at uint size so does not work
ConsoleWrite('!>' & Int($oD.Exists(Int($var1, 1))) & @CRLF) ; forced to int size

$t2 = DllStructCreate("int")
DllStructSetData($t2, 1, 22)
$var2 = DllStructGetData($t2, 1)
ConsoleWrite("INT:  " & Hex($var2) & @CRLF)

ConsoleWrite('!>' & Int($oD.Exists(22)) & @CRLF)
ConsoleWrite('!>' & Int($oD.Exists($var2)) & @CRLF) ; Works becsue int size
ConsoleWrite('!>' & Int($oD.Exists(Int($var2))) & @CRLF) ; autosized - left at int size so works
ConsoleWrite('!>' & Int($oD.Exists(Int($var2, 1))) & @CRLF) ; forced to int size

It looks to me as if the Scripting.Dictionary object is fussy about the size of its indices - but then someone clever will be along in a moment to tell me that as usual I am completely wrong when I dabble in stuff at this level.

M23

Edited January 5, 2014 by Melba23
Fixed tags

[asdf8]

Melba23,

Scripting.Dictionary - just for example AutoIt interaction with other components of Windows.

Yes, the behavior of Int matches the description in the help.

In my opinion, the behavior of Int in AutoIt 3.3.8.1 was more logical.

[Mat]

You can't fit a uint into an int, so when you get the data from the struct, you get it as a 64 bit signed integer. Calling Int($var) converts it to 32 bit. Then when you use the dictionary object it distinguishes between 32 and 64 bit integers.

None of your checks will show you any difference between 32 and 64 bit integers. To do that the easiest is call Hex($var) and see how long the string is.

I'm not sure there is an easy fix for this without breaking other stuff, so you are going to have to fix it yourself, either by always using 32 bit integers in code, or always using a particular type when it comes to the object code.

Edited January 5, 2014 by Mat

[Melba23]

mat,

 

Calling Int($var) converts it to 32 bit

No it does not and I think that is where the confusion lies. Int used without a flag auto-sizes:

 

"Default behavior is that if the result is within range of 32bit integer then 32bit integer is returned. If not, 64bit integer is returned. Both signed"

So as I pointed out, recovering a uint and using Int without specifying the size will leave it unchanged - hence the uint stays the same size. It is only by specifying the size by using the 1 flag that the correct size is returned.

M23

[Mat]

I stand corrected on that point Sortof anyway, it doesn't change size, but the docs implies that it should as 22 is in the range of a 32bit integer.

The rest of what I said is right though, the problem is that objects differentiate between the two, whereas AutoIt doesn't.

[Melba23]

Mat,

 

but the docs implies that it should

I do not read it that way as the value is passed as a 64-bit integer and so remains one.

 

the problem is that objects differentiate between the two, whereas AutoIt doesn't

But here I entirely agree with you - and see no reason why it should not be the user's problem to use the correct size to meet their requirement.

M23

[Mat]

I do not read it that way as the value is passed as a 64-bit integer and so remains one.

I read this sentence: "if the result is within range of 32bit integer then 32bit integer is returned" to mean it checks the value. In this case, it checks whether 22 is within range of 32 bit, which it is.

[Melba23]

Mat,

I read that as looking at the overall size of the value - which fits the observed behaviour. We obviously need to change it - how about this:

 

Default behaviour will not change size of the argument - a 32bit integer remains a 32bit integer; a 64bit integer a 64bit integer. Both signed.

M23

[jpm]

Hi,

the only case 32bit is not kept is when returning an Uint32 whos precision does not fit in Integer32

[trancexx]

Hi,

the only case 32bit is not kept is when returning an Uint32 whos precision does not fit in Integer32

jpm, I assume you changed default behavior for Int() function?

When default behavior is documented and you change it then you are making script breaking changes. I just checked changelog and I don't see any script breaking changes to Int() in 3.3.10 and newer. This is just terrible.

Changing documentation to fit new behavior without actually saying "Yes, this is script-breaking change" is being not serious.

[jpm]

No I didn't, I was trying to explain the behavior of DllStructGetData()

[Melba23]

trancexx,

We need to remove the confusion in the Help file about the correct default behaviour for the Int function. Is my suggestion above correct? If not, then what should it say?

M23

[jpm]

In fact not only DllstructGetData() is doing some conversion from Int32 to int64

$neg = -(0x80000000)

[trancexx]

trancexx,

We need to remove the confusion in the Help file about the correct default behaviour for the Int function. Is my suggestion above correct? If not, then what should it say?

M23

The OP shows that some scripts are possibly broken. I find it hard to believe that nobody knows how and why the default behavior got changed. Did anyone actuallly asked Jon what happened? If your code isn't affected by this change it doesn't mean other users don't have problems, or that they should be ignored as irrelevant factor.

If the change is deliberate then changelog misses script-breaking entry and new default behavior should be explained to you or whomever before documentation is updated by non-developer.

If the change is accidental then Jon should really try to find out what's the cause of it and make correction if possible. If it's not possible to correct it then again the new behavior should be correctly documented after changelog is updated with this script-breaking change.

But why am I saying this? Talk to Jon.

Btw and closely related, AutoIt has one (of few) major flaw. It over-advertizes internal integer types. That's the main problem with e.g. DllStruct types converted back and forth to AutoIt types. AutoIt should advertize only one integer type - Integer, regardless of the size. Everything else should be handled internally below user level.