Max Variable Length

[SmOke_N]

What is the Max Variable Length allowed?

I have found it to be 64 characters before an error is thrown, is this correct?

The help file says 64 dimensions for an Array under the variable but no mention of max character usage for the variable itself. And found nothing with Variable+Length here.

[JSThePatriot]

I am not positive, but I seem to remember it being some where in the range of 32767. That I cannot back up with the helpfile. I know a variable can hold many more than 62 characters. I have had a variable with darn near 500-1000 characters (If my estimations are correct).

My take,

JS

[themax90]

Perhaps a way of testing?

Global $Variable = "A"
Global $VariableAdd = "A"
While 1
    $Variable = $Variable & $VariableAdd
    If @Sec = 59 Then MsgBox(0, "Current Count", "Your variables current character count is " & StringLen($Variable))
WEnd
Func OnAutoItExit()
    MsgBox(0, "Exit", "AutoIt closed out with a variable count of " & StringLen($Variable))
EndFunc

Just a quick thought.

AutoIt Smith

Edited December 15, 2005 by AutoIt Smith

[themax90]

It supports about 200k until the processing power really slows down but I am at 250k and havn't found a crash yet

Edit 1: I'm at 300k now.

Edited December 15, 2005 by AutoIt Smith

[LxP]

What is the Max Variable Length allowed?

AutoIt Smith's code appears to test the length of a variable's content. The theoretical maximum according to the help file is 2,147,483,647 characters (from the FAQ). If you mean 'how long can a variable's identifer be' however, then there doesn't appear to be a theoretical maximum.

The script below attempts to set $AA, then $AAAA, then $AAAAAAAA, etc. (it doubles the length of the variable name each time). This script will hog CPU and memory rather quickly so be careful if you do run it.

Local $VarName = 'A'
Do
    $VarName &= $VarName
    If Not Assign($VarName, 'Test', 1) Then ExitLoop
    ToolTip(StringLen($VarName))
Until Eval($VarName) <> 'Test'
MsgBox(0, '', 'Could not set a variable with a name ' & StringLen($VarName) & ' characters long.')

[Valik]

LxP, that's not an accurate test. Assign() is notorious for not having much error checking as compared to using the language syntax itself.

When I read this, however, I ask the question, why do you care? Even if there was a limit at 64 characters, it should never be an issue. Identifiers that long are more difficult to read than short, descriptive identifiers. I don't know if there is a limit on the length or not from a technical perspective but from a code readability perspective, identifiers shouldn't be very long at all.

[seandisanti]

LxP, that's not an accurate test. Assign() is notorious for not having much error checking as compared to using the language syntax itself.

When I read this, however, I ask the question, why do you care? Even if there was a limit at 64 characters, it should never be an issue. Identifiers that long are more difficult to read than short, descriptive identifiers. I don't know if there is a limit on the length or not from a technical perspective but from a code readability perspective, identifiers shouldn't be very long at all.

unless you're intentionally trying to reduce readability, in which case i'd think it a valid question...

[SmOke_N]

When I read this, however, I ask the question, why do you care? Even if there was a limit at 64 characters, it should never be an issue.

Never said it was an issue, it was more for plain curiousity. I can't seem to replicate it at the moment either, so it must have been my mistake

[herewasplato]

LxP, that's not an accurate test. Assign() is notorious for not...

Then perhaps this test will do:

HotKeySet("{PAUSE}", "Terminate")

$tmp = ""
ClipPut("")
Sleep(200)

For $i = 1 To 4090
    $tmp = $tmp & "1"
Next

ClipPut("$" & $tmp & "=''" & @LF & 'MsgBox(0,"",' & StringLen($tmp) & ')')

FileWrite(FileOpen("c:\temp\temp.au3", 2), ClipGet())
FileClose("c:\temp\temp.au3")
Run(@AutoItExe & " c:\temp\temp.au3")

Exit
Func Terminate()
    Exit
EndFunc

Just manually increment the "4090" in the For/Next loop above.

Edit2: See here for an explanation of the code layout shown above and the rationale for using ClipPut/ClipGet.

It seems to be more related to:

"Maximum length of a single script line: 4,095"

To quote SmOke_N, "...it was more for plain curiousity".

Edit1: Replaced @CRLF with just @LF

Edited December 16, 2005 by herewasplato

[SmOke_N]

It seems to be more related to:

"Maximum length of a single script line: 4,095"

@HWP - That may have been the issue now that I think about it...

@cameronsdad - whatever do you mean

Edited December 15, 2005 by SmOke_N

[w0uter]

Then perhaps this test will do

damn that code is so bugged.

most if it is obsolete and other things wont even do what you want.

to be honest i wouldnt even expect code like this from someone who got autoit a day ago.

this is probly what you ment:

HotKeySet("{PAUSE}", "Terminate")

dim $s_tmp = "", $h_andle

For $i = 1 To 4092
    $s_tmp &= "a"
    
    $h_andle = FileOpen("c:\temp\temp.au3", 2)
    FileWrite($h_andle, '$' & $s_tmp & '=0')
    FileClose($h_andle)
    
    ConsoleWrite($i & @LF)
    
    RunWait(@AutoItExe & " c:\temp\temp.au3")
Next

Func Terminate()
    Exit
EndFunc

Edited December 15, 2005 by w0uter

[Valuater]

@cameronsdad - whatever do you mean

Awwwhhh.... and i thought maybe you were the "one"

cameronsdad currently has a poll on a misterious "someone" writing a script/program that can help protect our script/programs

8)

[seandisanti]

Awwwhhh.... and i thought maybe you were the "one"

cameronsdad currently has a poll on a misterious "someone" writing a script/program that can help protect our script/programs

8)

neat. this is my 1000'th post, and i'm wasting it just to let everyone know.

[Valik]

unless you're intentionally trying to reduce readability, in which case i'd think it a valid question...

If you're referring to obfuscating the code by making extraordinarily long variable names, I can shorten then with a simple regular expression.

[LxP]

LxP, that's not an accurate test. Assign() is notorious for not having much error checking as compared to using the language syntax itself.

I attempted to counter this via the Eval() call on the Until line. The script continued to run past a length of 16,000,000 on my system which suggested to me at the time that this should be adequate.

[Valik]

Ditto my comment about Assign() only replace "Assign" with "Eval".

[herewasplato]

...this is probly what you ment:

Nope. I meant what I posted. I did not want to creep up on the answer by starting at 1 and running the temp.au3 script 4000+ times. I thought that I knew the number to test. I tested 4090 and 4095 and I had my answer... the "4095 limit" is the issue. You are correct that such a code layout would not be the best for a large range of numbers.

I understand that the ClipPut/ClipGet looks weird, but understand that this was recycled code that I had used to test problems with the clipboard functions after large data swaps. I just added the loop and tweaked the ClipPut line. I thought it was a rather clever recycle... but thanks for your rewrite, I did study it.

Edited December 16, 2005 by herewasplato

[LxP]

Ditto my comment about Assign() only replace "Assign" with "Eval".

But if an Assign() fails then surely Eval() won't return a specific value like 'Test'...? I don't think I understand what you're saying then.

Edit: Yes, the Eval() may of course possibly fail even if the Assign() within that iteration doesn't, however I don't see how the While loop can reiterate if the Assign() fails because the Eval() will also fail without doubt. Can you please further explain what you mean?

Edited December 16, 2005 by LxP

[Valik]

But if an Assign() fails then surely Eval() won't return a specific value like 'Test'...? I don't think I understand what you're saying then.

Edit: Yes, the Eval() may of course possibly fail even if the Assign() within that iteration doesn't, however I don't see how the While loop can reiterate if the Assign() fails because the Eval() will also fail without doubt. Can you please further explain what you mean?

Speaking in a hypothetical sense, there are two places checking can be done for the length of a variable name. The first would be done during the pre-run syntax checking. The second would be in the variable-related code which handles the creation/storage of variables. If the check for variable length was performed in the first location, Assign() and Eval() would both bypass this check an essentially invoke undefined behavior. If the check were in the second location, then Assign() would obey the same rules as a statically declared variable and thus both Assign() and Eval() would fail.

I don't know if there is a limit to the length of a variable name. If there is a check, I would place a large sum of money in it being in the first location and not the second location. With all that being said, the chances of Assign() and Eval() doing the right thing are next to none.

This is of course all speculation on my part. However, since I wrote Assign(), I know that it's a maintenance liability with regards to keeping it's behavior consistent with the more traditional method of assigning variables so with that knowledge in mind, Assign() is not suitable for this test.

[LxP]

Thanks Valik; I better understand what you mean now.

You seem to suggest that (as an example) a request to Assign() or Eval() a variable whose name consists of 500 Xs may in fact create/operate on a variable whose name consists of 250 Xs (or some other arbitrary number less than 500). Hence an Eval() following an Assign() does not guarantee success as they both may be checking a different variable (although both would check the same different variable).

This can be likened to labels in DOS batch files, where only the first 8 characters are used and therefore Label1234 is equivalent to Label1235.