Forums Bug Reports IF Bug

Will be true even though 1 is not in 2-4.



So shouldn't ((1 && 2) isnum 2-4) be false?

That looks like an invalid arguement structure, that managed to slip through the parser to me.

(1 && 2) should produce a $true or $false value (obviously), which you should not be able to use in ISNUM anything.

However what appears to actually happen is (1 && 2) is evaluated as $true so the ISNUM is processed using the last value ie:2, thus "2 ISNUM 2-4" is also $true, so the True condition is reached.

It seems to be an obscure but possably usefull speeding up of IF conditions

Take this normalish code for example....
var %on = 1, var %light = $1 | if (%on && (%light isnum $+(1-,$maxactivelights)))

could use this to become...
var %on = 1, var %light = $1 | if ((%on && %light) isnum $+(1-,$maxactivelights))

^ due to if %light had no value or it was 0 then the first condition would fail, and mirc would not need to evaluate the ISNUM with its alias $identifier, thus speeding up the proces.
* not an overly exciting saving here but in some calculation being performed 100's or 1000's of times, i can see every tweak being important.

---

Another possable cause for this is how mirc processes the IF take for example
//IF (1 && 2 && 3 && 4) { echo TRUE $!v1 = $v1 : $!v2 = $v2 }
TRUE $v1 = 4 : $v2 =

^ this shows that each of the values is considered the sole conditional value, and if true the IF continues, resulting in the last IF condition being soley "4"
now assume it incounters a ISNUM without a lefthand value it may fall back onto the last $v1 (in this case 4, in yours 2) for the ISNUM

---

And interesting one i found while experemneting was this
//if ((1 == 1) isnum (1 == 1)) { echo TRUE $v1 : $v2 } | else { echo FALSE $v1 : $v2 }
<no result>

it should have been true or false or errored shouldnt it?

To me it looks more like mirc stripping off () pairs until it comes up with something workable.

In Stealth's case, the statement is invalid in mirc: expressions (boolean or not) don't return values in mirc, like they do in other languages, e.g. (1 + 2) doesn't work unless it's inside $calc(). So
if ((1 && 2) isnum 2-4)
after ignoring () pair(s), is considered to be:
if (1 && 2 isnum 2-4)
or
if 1 && 2 isnum 2-4
both of which are equivalent to:
if ((1) && (2 isnum 2-4))
which is TRUE.

I tried different cases like changing && to ||, 1 to 0 and 2 to a number out of the 2-4 range and all seemed to work like that.

About your last example, mirc does indeed do something: it executes the /isnum command (which, if connected, will be sent to the server instead of giving an error; probably why you missed it). Apparently, the outer () pair is ignored, so the "(v1 operator v2)" part is
(1 == 1)
and the "command" part is
isnum (1 == 1) { echo TRUE $v1 : $v2 }


Bottom line, I'm not sure if we can call this a bug (although I'd prefer if (1 && 2) echo ok to work and not give "/if: 'echo' unknown operator"). To me, this behaviour is consistent with mirc's general lenience towards syntax stretches: it tries to do the closest logical thing to one's 'illogical' syntax.

I see what your meaning by stripping the ( ), that sounds far more logical, it sees the isnum, and steps backward in some way for the number.
One thing i did incounter tho is it processes if ((1 && 2) isnum 2-4) like if (1) { if (2) { if (2 isnum 2-4) { ..., ie: if 2 was was infact 0 then it well never do the ISNUM.



Doh!, i had something running that if it gets them UNKNOWN COMMANDS from the server in mass, it disconnects me, a kinda "your scripts bellied up , disconnect so you dont flood the hell outa the server" kinda thing, forgot it was loaded on that mirc , my mistake

* think i got it, it ignores trailing brakets, just like a $calc would (assuming the ) was in the variable. //var %x = 45) | echo -a $calc(1 * %x)

i used these...
//if ((1 && 1) isnum 234-999) { echo TRUE $v1 : $v2 } | else { echo FALSE $v1 : $v2 }
FALSE 1 : 234-999
//if ((1 && 1) isnum (234-999)) { echo TRUE $v1 : $v2 } | else { echo FALSE $v1 : $v2 }
TRUE 1 : (234-999)
//if ((1 && -1) isnum (234-999)) { echo TRUE $v1 : $v2 } | else { echo FALSE $v1 : $v2 }
FALSE -1: (234-999)

1) becomes 1, -1) becomes -1
(234 becomes 0 and 999) becomes 999 aka ISNUM 0-999

If you use 0 instead of 2, the check is done but the result is FALSE, since 0 is not in range 2-4. If you change 2-4 to 0-4, you'll notice that it works:
//if ((1 && 0) isnum 0-4) { echo -s $v1 : $v2 }
gives "0 : 0-4"




I'm not so sure it does that. Generally, it looks like it ignores pairs of brackets (opening AND closing), but there's also something definitely wrong with isnum (and the reason you get those results from your last examples):

//if 2 isnum (((1-3) { echo TRUE $v1 : $v2 } | else echo FALSE $v1 : $v2
TRUE 2 : (((1-3)

//var %a = (1-3))) | if (2 isnum %a) { echo TRUE $v1 : $v2 } | else echo FALSE $v1 : $v2
TRUE 2 : (1-3)))

So far so good. It *looks* like isnum ignores brackets around v2, even if they are unpaired. Now watch this:
//var %a = (3-4) | if (2 isnum %a) { echo TRUE $v1 : $v2 } | else echo FALSE $v1 : $v2
TRUE 2 : (3-4)

//var %a = (3-) | if (2 isnum %a) { echo TRUE $v1 : $v2 } | else echo FALSE $v1 : $v2
FALSE 2 : (3-)

//var %a = (1-) | if (2 isnum %a) { echo TRUE $v1 : $v2 } | else echo FALSE $v1 : $v2
FALSE 2 : (1-)

These last results should be considered a bug, since we're not stretching syntax here, just filling v2 with something mirc doesn't expect.

oops definitely my mistake, i made an assumption with out checking deeper

i had been testing with things like this

alias x { echo -s $+(x,$1,:,$2) | return $2 }
//if (($x(a,1) && $x(b,0) && $x(c,0)) isnum $+($x(d,0),-,$x(e,4))) { echo -s $v1 : $v2 }
xa:1
xb:0

you are correct of course as this results with
//if (($x(a,1) && $x(b,0)) isnum $+($x(c,0),-,$x(d,4))) { echo -s $v1 : $v2 }
xa:1
xb:0
xc:0
xd:4
0 : 0-4

if ((1 && 0) isnum 0-4) TRUE
if ((1 && 0 && 0) isnum 0-4) FALSE

which leads to your orginial conculsion being correct
if ((1 && 0) isnum 0-4) TRUE becomes if ((1) && (0 isnum 0-4)) TRUE

/me thinks im wasting good sleeping time on these tests!



To me both those followed what i said,
(3-) becomes (3 & ), (3=0, )=0, making if (2 isnum 0-0)
(1-) becomes (1 & ), (1=0, )=0, making if (2 isnum 0-0)

Ahh I see what you mean, the strings to left and right of the dash are separated and atoi()'ed. I didn't actually catch that from your previous post (was it the part about ignoring trailing brackets?), but you seem to be right, all tests I made confirm this. Makes much more sense now