Forums Bug Reports /var is an alias for /set -l

i noticed this when i made an alias like this:
set { echo -a $1- }
then, for the following statements:

var %y = y
%y = yy

would echo as:

-l %y y
%y yy

so i'm guessing that /var is replaced by the mirc interpreter by /set -l , leaving /var variables nothing but /set variables, marked with -l in advance, probably to avoid namespace conflicts/limit the scope.
and i'm a tad bit disappointed by this fact. for loops etc, i always used /var variables, assuming that, as in most programming languages, local variables would be handled faster. i guess it's ok to use the heap for global /set variables, but why not use registers or the stack for local variables?
moreover, this hardcoded aliasing is a security leak that can easily be exploited. for instance, normally it isn't (and shouldn't!) be possible to use an evaluated expression to set local variables. what i mean is that a script like this:

a { return var $+($chr(37),x) 1 }
b {
$a
echo -a %x
}

won't work (* /var: not connected to server...), apparently because /var is not an official mirc command (and now we know why!). however, the following:

a { return set -l $+($chr(37),x) 1 }
b {
$a
echo -a %x
}

works fine and outputs:

1

which is like saying yes to having any alias creating and setting variables, local to the alias from which it was called! besides that, the /set -l switch is not described in the mirc helpfile, from which i infer that it is hidden just for the purpose of forcing the use of a /var replacement acting as a workaround to assure that local variables can not be externally modified, all the while knowing that they can. dirty programming? perhaps, but it's definitely not a feature.

"i guess it's ok to use the heap for global /set variables, but why not use registers or the stack for local variables?"

Why did you assume that the fact that /var is an alias for /set -l means that local variables are made on the heap? Or did I misunderstand something here?
Btw, I don't think this little detail would matter in an already "slow" (compared to C++) environment like mirc. It sounds to me like saying that it would make a difference if you travelled the first 10 meters of a 100-kilometer distance by airplane and the rest 99990 meters by car, instead of using the car for all 100 kilometers.


"moreover, this hardcoded aliasing is a security leak that can easily be exploited. for instance, normally it isn't (and shouldn't!) be possible to use an evaluated expression to set local variables"

It may be forbidden to modify a local var externally (or set a local var by an evaluated expression) in a programming language, but in scripting I don't consider this (and other similar things mirc does) bad. Inconsistency? Maybe, but I like it
But even if you disagree on the above, I still fail to see your point. How could this thing be exploited and by whom? Anything that has the permission to run aliases in mirc can do anything (including much worse things than setting local variables :P). In your example, if the scripter allows b to run the a alias, he should know what a does. If by "security leak" you mean a discrepancy on a theoretical level then yes, it is a security leak; just let's make it clear that it's not a security leak in any dangerous way.


Anyway, I don't like the /var story either, but for other reasons.
1) It's buggy. Try setting a dynamic local var with /var (//var %a $+ $me = 1): you'll find out that the "=" is included in the value. Generally, I don't trust /var as much as I trust /set -l (I've considered using /set -l in my scripts instead of /var but in most cases I don't, because it's undocumented and because /var allows you to set multiple vars at once).
2) It's an internal alias, which means that (according to what one would expect but also according to benchmarks) it is slower than /set -l.



Now, what do you make of that?