Forums Bug Reports Crazy /var bug; double-evaluation math

mIRC is evaluating the contents of an identifier when the /var command is used to define a variable. If the identifier contains a simple single-operator math expression, mIRC will store the solution to the expression and not the string itself.

This can be potentially exploited with user input.

This CAN NOT be treated with any known work-arounds, short of replacing spaces with $chr(160).

EXAMPLE 1:

On *:TEXT:*:#: { var %a = $1- | echo -a %a }

<Raccoon> Hi
OUTPUT: Hi
<Raccoon> 1 + 1
OUTPUT: 2
(should be: 1 + 1)

EXAMPLE 2:

//var %a = $qt(1 + 1), %b = $noqt(%a) | echo -a %a , %b

OUTPUT: "1 + 1" , 2

v7.29

UPDATE:

I was informed a functioning work around is to use /set -nl %a $1- instead of /var %a = $1-

This is not an issue with /var itself. The /var command can perform simple calculations in the same way as /set. Both of these commands are used by many scripts for this purpose. It would not be possible to make changes to how these commands work without affecting all existing scripts.

The /set command has an -n switch that allows you to store input without evaluating it, as you discovered. The -n switch is not available in /var, which only supports a subset of the switches available to /set. I will add this switch to /var in the next version.

Thanks, Khaled!

I'm surprised I've never encountered this before with handling user input and storing On Text $1- to a variable. Seems all these years someone must have typed "1 + 1" and my client would have thought they said "2".

I thought the Simple Math behavior of /set and /var was only with explicit assignments and not through evaluation of another variable or identifier... for which one would use $calc() instead.

Hello Khaled, I suggested that in the past, as well as having the -u switch (with -g: var -gu), any way to also add -u in the next version ?