Assignment or VarSetCapacity bug & internal string length, AHK 1.1.29.00

[SAbboushi]

[Moderator's note: Topic moved from Bug Reports.]

Code: Select all

#NoEnv
#SingleInstance Force ; 

var1 := 123
var1capacity := VarSetCapacity(var1) ; bizarre: why 0?  Seems AHK failed to update AHK's internally-stored string length?  If Variable List in SciTE4AutoHotkey is opened while debugging before executing this line, then value is 3 if ANSI, 6 if Unicode!!!  Shouldn't need to set string length manually here (i.e. VarSetCapacity(var1, -1) unless I'm missing something?
MsgBox % var1capacity

[Helgef]

It is not a string. When Needed , the number will be converted to one.

[SAbboushi]

Thanks - your response leads me to believe you don't consider this a bug?

>> It is not a string
Thanks -- let me know if you have any insight as to why var1capacity = 0 instead of 3. If you object to the terminology, maybe you can make a suggestion to update the VarSetCapacity() documentation e.g. "Specify -1 for RequestedCapacity to update the variable's internally-stored string length to the length of its current contents."

>> When Needed , the number will be converted to one.
I'm not sure how you define "Needed": the variable var1capacity needed the variable length and received an incorrect one...?

[nnnik]

You seem to misunderstand - it's not the variables length that VarSetCapacity returns. It's the current storage capacity of a variables string buffer - meaning the part in it that stores it's text. However your variable doesn't store text - it contains a number.

[SAbboushi]

Thanks - I agree that I seem to be misunderstanding something ; )

I think I'm getting confused because of AHK caching: "Taking the address of a variable effectively converts the variable's value to a string, disabling caching until the variable's address changes (this happens when its capacity changes). This is both for backward-compatibility and because the script could change the value indirectly via its address at any time, making the cache inaccurate."

The only way I know how to examine how a value is stored is using NumGet() and StrGet(); but "Taking the address of a variable effectively converts the variable's value to a string...", so I don't know how to see that the "number" 123 is stored in the var1 memory buffer.

It seems that SciTE4AutoHotkey "sees" things like I do, and that its act of "Taking the address of [var1 so that it can display its value in the debugger] effectively converts the variable's value to a string...", hence capacity of var1 becomes 3 (and 1 zero terminator byte).

Is there a way for me to examine the value of var1 in memory to see that it is stored as the decimal 123 instead of the 3 bytes I see using NumGet/StrGet?

Hopefully what I've written here will offer some clues as to where my understanding is incorrect?

[SAbboushi]

Helgef - thanks again. I think I now understand what you were saying. Just to confirm, I'm not trying to solve a problem here; I'm trying to learn/understand how AHK stores variables/values and how to examine what was stored as part of my learning process for DllCalls. Any further help on my questions/statements in this thread would be appreciated

[nnnik]

Well no I dont think thats neccessary. What are you going to use this for?
You could always read the AHK source if you really want to find out what a variable is.

[jeeswg]

- For strings and DllCall, if the string buffer is going to receive some text, you need to use VarSetCapacity, so that there is enough space to receive the string.
- For numbers and DllCall, e.g. Int and Int* (aka IntP), you don't need to be concerned with VarSetCapacity ever. (Hardly ever? I can't think of any exceptions.)

[SAbboushi]

Well no I dont think thats neccessary.

Not sure what you are referring to...

What are you going to use this for?

No specific application other than wanting to understand how things work

You could always read the AHK source if you really want to find out what a variable is.

He He! Spent most of the past month getting to the next level with AHK -- maybe next round I can try that (i.e. examining C++ code?). Hoping in the meantime some of you experts can satisfy my questions.

jeeswg: thanks for the practical advise

From responses so far and pouring through the documentation, I'm left with the impression that AHK doesn't provide a means to examine the memory locations used to store a variable's contents in the case where a variable's value is a number... that some caching is going on whereby AutoHotkey automatically converts between numbers and strings, and the mere act of referencing a variable's address effectively converts the variable's value to a string, disabling caching until the variable's address changes. Bottom line: Although a variable can contain both a string and a number simultaneously, it looks like AHK only provides the means for me to examine the string value as it is stored in memory and not the number, correct?

[Helgef]

Hello, sorry for the unhelpful answer, it seems you got it in the end anyways .

In v2, this mess is mostly fixed, &(var := 123) returns the address of a (signed) 8 byte integer, no string conversion involved. And varsetcapacity return 6. (if I recall correctly )

Cheers.

[nnnik]

You dont need to examine the way a number is stored.
It can only ever be a double or a 64 bit integer.
If you want to learn about those data types I reccomend readong up on them rather than analyzing the date thats used to store them.

[jeeswg]

- @nnnik: AHK appears to let you get the address of a string, but not a number. Why not allow both? Is there a sneaky way to achieve this?
- This kind of experimentation is one of the best ways to learn things, and often results in useful techniques. I was able to do some really good hacks involving ClipboardAll and editing/retrieving bitmap data for example.
- Also, being able to retrieve the reference count of an object directly, via NumGet, really helped me to understand reference counts, including the effect of passing an object ByRef versus ByVal into a function (using ByVal increases the count), and thereby use them correctly.

[nnnik]

I consider useful hacks "trash". They often depend on undocumented behaviour and stuff like that and will break once a new version comes out.
Also the string part of AHKs variables is only accessible in binary format because it is also used as a binary storage.
This capability might also be removed once AHK actually decides to use a seperate binary data format.

The actual best way to find "useful hacks" is by looking at the source.

[jeeswg]

@nnnik: I use standard techniques wherever possible, however, using hacks allows you to automate some things that you couldn't otherwise automate, and even if the software later changes, you can check the version number, and apply a hack accordingly.

[SAbboushi]

In v2, this mess is mostly fixed

Great! That's where I'm headed next

This kind of experimentation is one of the best ways to learn things, and often results in useful techniques.

That's certainly my experience

being able to retrieve the reference count of an object directly, via NumGet, really helped me to understand reference counts, including the effect of passing an object ByRef versus ByVal into a function (using ByVal increases the count), and thereby use them correctly.

Do tell: how do I do that? I was trying to figure that out yesterday but couldn't find how to get that info on MSDN or AHK forum

Thanks folks for your advice and assistance--

[jeeswg]

- I used NumGet to experiment (an undocumented technique that shouldn't be relied on).
- That experimenting showed that I could use ObjAddRef and ObjRelease (documented techniques) to get the ref count.
object classes: redefine __Set() temporarily / general queries - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 68#p195068

- There were some issues with COM objects btw:
object classes: redefine __Set() temporarily / general queries - Page 2 - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 33#p195133

[SAbboushi]

k thanks

[SAbboushi]

You dont need to examine the way a number is stored.
It can only ever be a double or a 64 bit integer

So any idea why I'm getting an empty string and 0 (AHK ANSI)?:

Code: Select all

var1 := 123
PureNumber1 := NumGet(var1,"Int64") ; returns empty

var2 := 456.
PureNumber2 := NumGet(var2,"Double") ; returns 0.000000

[SAbboushi]

Anyone?

[just me]

Code: Select all

NumGet(var1,"Int64") ; returns empty

always tries to access the string buffer of var1 which will be created if necessary. If something is stored in that buffer, it will be a sequence of characters - UChars (ANSI) or UShorts (Unicode) - but never an Int64 or Double. You cannot access a variable's internal number cache directly.