AutoHotkey Community

Just run this (I understand it's for performance but at least it should be documented):

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

I get a blank message box (running the latest AHK version).

Same here.

_________________
"Read the manual. Read it again. Search the forum.
Try something before asking. Show what you've tried."

Antonio França
My stuff: Google Profile

I'm also using the vanilla version of AutoHotkey v1.0.48.05 (no Unicode/_L stuff involved). Am I missing something here?

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

It's the #NoEnv directive that's causing this to happen

Confirmed.

_________________
"Read the manual. Read it again. Search the forum.
Try something before asking. Show what you've tried."

Antonio França
My stuff: Google Profile

Unless I'm missing something, this is a documented condition (feature) and it includes local variables that are defined within functions. fincs just exposed a means of getting at memory that has not been released. You can duplicate this "problem" with global variables. Just create a global variable to something with a length that is less than 64 bytes, set the variable to null, and then use fincs' trick for reallocating the memory. Something like this:


For all (OK, most) practical purposes, the variable does not exist when you use it again. The string length is zero and if you test the variable, i.e. If MyVariable, it will test as False. All string commands such as StringLeft, StringLower StringMid, etc. are not affected.

Them be my thoughts...

What's happening here is that the first character of the discarded variable is set to NULL, and since ahk's strings are null-terminated this essentially makes the string a length of 0. By overwriting the null character with another character, the remaining string is visible again until the next null character. (which is now at the end of the first string because, as jballi mentioned, it's length is < 64 bytes and it is never really freed in the true sense)

I think.



Edit:

"All string commands such as StringLeft, StringLower StringMid, etc. are not affected."

This, too can be explained by the fact that ahk keeps a separate record of the length of the string in a given variable, which is set to 0 when cleared. All the string commands refer to this value for validating values, which can save it a lot of time vs going through the entire string to find the null char every time someone uses a string command.

_________________
Scripts - License

What do you want to happen when you use NumPut on an "uninitialized" variable? Variables are not guaranteed to be zero-initialized unless you specifically do it yourself.

If #NoEnv is not present, AutoHotkey looks for an environment variable when the variable's internal "length" field is 0. Even if there is no environment variable, it does not use the variable's actual contents in that case. #NoEnv itself is not in any way responsible for the effect demonstarted by fincs and jballi.

OT: #NoEnv is important for performance because without it, every time you evaluate an empty variable, the script has to search for an environment variable by the same name. Even having this mechanism present (with or without #NoEnv) negatively affects performance of all scripts, though perhaps not noticably.

Just look at this case (I only want it to be documented!):

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

I think you missed my point.

"All local variables start of blank each time the function is called," but this only means a null-terminator is set at the beginning of the variable. Any content following the null-terminator is initially undefined, so relying on its value is asking for trouble. Documenting that local variables might "retain" their contents between calls would be counterproductive since the contents are still undefined in other situations.

On the other hand, it might be worth clarifying how variables are "initialized". VarSetCapacity hints at it:

Local variables are freed or cleared when the function returns in the same way as VarSetCapacity(var,0), so the following applies:
However, it only might have no effect, so you can't rely on it. If d_data extends beyond 63 bytes, it becomes non-permanent and will be freed when the function returns. Undocumented: In all subsequent calls it will receive non-permanent memory. VarSetCapacity will allocate exactly the length requested (plus 1) and will null-terminate in the correct position every time. This behaviour can be forced:

Btw, even if the variable's contents are freed, there's no guarantee that the same memory won't be allocated to that variable (or a different variable) at some later point. A variable could hypothetically even be allocated different memory with contents identical to what it had previously.

First off, thanks to jballi, infogulch, and Lexikos. Your explanations were all very informative. I learned something today.

I think the issue is not about changing the behavior of NumPut, but about how variables should be referenced (e.g. after Numput has been used).

A variable's actual contents should never be used when its internal length field is 0. The message box should always show blank, regardless of #NoEnv.

If the internal length field is inaccurate, why should it be used over the contents of the variable? It is usually disregarded in simple cases:
Changing the behaviour to always respect the internal length field (for consistency) would require a copy to be made of the arg where ordinarily it could get away with using the string directly. In other words, the performance benefit of the internal length field could be negated.

While I was researching this, I noticed that some areas use the internal length field (indirectly) and then assume the arg is null-terminated at that position. In particular, parsing loops allocate a buffer based on the "length" of the arg, then disregard that length and do a simple string copy:
This can cause stack or heap corruption:
Parsing loops use the stack for anything <= 40000 characters and the heap (malloc) otherwise.
Right. I meant "after" vs "when".

Ok, I can accept that. Performance trumps all. I also was not aware that the internal length could be updated manually, which at least offers a bit of control over the behavior.