Forums Bug Reports $iif as second operator

returns "not equal".


works fine.


this code again, does not work.
this also returns "not equal".

So it's only when the $iif is placed on the right side of the operator.

I have a feeling it just doesn't evaluate the other side of the ==. I could be wrong, though.

Try something other than null...

AFAIK, $null is usually considered an instant false, so try something that actually has a value. $null means nothing at all, so you are essentially saying: if (==) { do stuff }

Actually everything is evaluating just fine, contrary to what it seems to be doing. Proof:

//if ( $null == $iif($null,$null,$!null) ) echo -a equal | else echo -a not equal

It now returns equal as it should.

mIRC is evaluating that $iif and returning $null, but $null returned by an $iif seems to have a different meaning that probably holds some importance when used elsewhere (Also notice $iif can take 2 params, in that case a '$null' 3rd param is implied).

So this is an issue with using $null as a third parameter.

From the beginning I was wondering why you were using all those $nulls in your example to begin with, they definitely don't help isolate the problem.

//if ( $me == $iif($null,$null,$me) ) echo -a equal | else echo -a not equal
You'll notice that the $iif is evaluated even when it's the second parameter, it just doesn't react to $null well.

This doesn't look like a bug to me, rather a feature of $iif that probably has an important role somewhere else in the language. Instead of saying mIRC is not correctly reacting to your code, it's easier to say that your code is not correctly written for mIRC's reaction..

Quirky as the answer seems, you can also write it as:

//if ( $null == $($iif($null,$null),2) ) echo -a equal | else echo -a not equal

which is even quirkier, since its the exact opposite of the first solution.

Nevertheless, enclose the $iif inside an $eval inside an if statement and the problem wont exist.

I believe the problem actually exists in the IF statment and not the $iif at all.

The Problem as I see it maybe is with the way mirc appears to have to pass zero length strings

//if ( $iif($null,$null,$null) == $iif($null,$null,$null) ) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,') ~ $!null = $+(',$null,')
or
//if ( $null == $iif($null,$null,$null) ) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,') ~ $!null = $+(',$null,')
not equal
$v1 = '$null' ~ $v2 = '' ~ $null = ''

Well its pretty clear that $ n u l l is not the same as a zero length string, but what isnt clear is what causes it.

this works fine
//if ( $null == $null) ) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,') ~ $!null = $+(',$null,')
equal
$v1 = '' ~ $v2 = '' ~ $null = ''

A more desturbing image of the incorrect result is this
//if ( fixedtext $remove(a,a) == fixedtext $iif($null,$null,$null)) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,') ~ $!null = $+(',$null,')
not equal
$v1 = 'fixedtext $null' ~ $v2 = 'fixedtext ' ~ $null = ''

From my checking it appears when there was a $iif inside the second operator, its like the first operator is somehow not correctly processed, the $null return from $remove (which i never released it even returned like that untill now) is not processed into an actual zero length string.

//if ( fixedtext $remove(a,a) $+ 3 == fixedtext $iif(1=2,3,4)) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,')
not equal
$v1 = 'fixedtext $null' ~ $v2 = 'fixedtext 3'

As you can see there is no $NULL mentioned at al;l in the above example yet it still produced a $null in the first side of the arguement.

Finally i sort a fix, this seemed to work
//if ( $null $+ $iif($null,$null,$null) == $iif($null,$null,$null) ) { echo -a equal } | else { echo -a not equal }
equal

This maybe simply causing the first side to have to be completely processed before mirc moves onto the second side.

You're trying to rule out $iif being the cause of the problem and using $iif in your proof?

I don't get it.

If the problem was the IF statement and not the $iif as you said, you would be able to reproduce it without an $iif entirely.

Moreover, you would be able to reproduce it without a $null as a third parameter....

Finally, the code snippets you posted gave me different results:

//if ( fixedtext $remove(a,a) $+ 3 == fixedtext $iif(1=2,3,4)) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,')

returns:
equal
$v1 = 'fixedtext 3' ~ $v2 = 'fixedtext 3'


As i said before, a $null returned from an $iif is the real problem here, because it doesnt return the $null back to the if statement like other identifiers can ($remove(a,a)). Instead it returns nothing at all, an empty string, making mirc compare $null to...well...nothing.


If anything, $iif should be corrected to return $null and not '', but I have this strange feeling that there is an important reason it works the way it does

Nope, $iif() doesn't have to return $null for the problem to occur. My findings support DaveC's conclusion that it has to do v2 being $iif() and v1 having a $null-returning ident. To sum it up, when all of the following are true in an /if statement:
1. v1 contains a top-level identifier/variable that returns $null and does not have a $+ on either side.
2. v2 contains an $iif() that is not inside square brackets
mirc replaces the $null (ie the empty string) returned by that identifier/variable with the actual string "$null". By "top-level" I mean that the bug doesn't appear when a nested identifier/var returns $null, as long as the identifier that encloses the former does not return $null.

Examples:
//if $str(a,0) == $iif(1,2,3) { echo 3 true: $v1 :: $v2 } | else echo 4 false: $v1 :: $v2

//if $+(A,$str(a,0)) == $iif(1,A,B) { echo 3 true: $v1 :: $v2 } | else echo 4 false: $v1 :: $v2

I simply don't know enough to say which is at fault, /if or $iif(), and it doesn't matter to anybody but Khaled himself. This is actually a member of a really old family of bugs regarding $null being incorrectly treated as the string "$null".

Your right about that output I copied the wrong line in, definitely my fault on that, it was ment to be...
//if ( fixedtext $remove(a,a) == fixedtext $iif(1=2,3,4)) { echo -a equal } | else { echo -a not equal } | echo -a $!v1 = $+(',$v1,') ~ $!v2 = $+(',$v2,')
not equal
$v1 = 'fixedtext $null' ~ $v2 = 'fixedtext 3'
An error on my part from running to many test one after each other to see how different things react, the $+ of course caused the $null to be evaluated correctly to nothing.


As Qwerty has said, I dont think its to do with $iif return rather IF going haywire if there is a $iif on the right hand side.
However I dont really know which one to say the problem would be in


This is what i believe is happening, when an $identifier returns nothing its returned as $null, this in most places means its just that nothing
//echo The 9th get nick is ' $get(9) '
The 9th get nick is ' '

The $get(9) is returned as $null and replaced with nothing straight away
Possable support of that is this
//var -s %ex = $replace(The 9th get nick is ' $get(9) ',$chr(32),^)
* Set %ex to The^9th^get^nick^is^'^'

However when a $identifier returns $null inside a IF or $iif condition section it cant be replaced straight away
example if it was...
//if ( $get(9) != DaveC ) { echo -a DaveC is not the 9th sender it is $+(',$v1,'.) nicklen $len($v1) }
//if ( != DaveC ) { echo -a DaveC is not the 9th sender it is $+(',$v1,'.) nicklen $len($v1) }
* /if: invalid format

So instead it isnt instantly replaced (but is afterwards) giving
//if ( $get(9) != DaveC ) { echo -a DaveC is not the 9th sender it is $+(',$v1,'.) nicklen $len($v1) }
//if ( $null != DaveC ) { echo -a DaveC is not the 9th sender it is $+(',$v1,') }
DaveC is not the 9th sender it is ''. nicklen 0
^ As you well note $v1 does not contain "$null" as it should of course not

Watch what happens here if I insert a seamingly unimportant $iif
//if ( $get(9) != $iif(1,DaveC) ) { echo -a DaveC is not the 9th sender it is $+(',$v1,'.) nicklen $len($v1) }
//if ( $null != DaveC ) { echo -a DaveC is not the 9th sender it is $+(',$v1,'.) nicklen $len($v1) }
DaveC is not the 9th sender it is '$null'. nicklen 5


What i believe happens is when the code enters a /IF (or $iif) there is some type of flag that gets set to true such as "DOING.A.IF"
And any $null returns when this flag is true are not replaced automaticly with nothing, as the /IF or $iif completes it well do this
replacing becuase the flag is set.
Now the problem occurs becuase the simple $iif(1,DaveC) sets the flag then resets it as it finishes. Now the return value in this
$iif is not $null but if it was the retuned $null would be replaced with nothing all following $null would also be replaced with nothing.
But more importantly when the /IF completes becuase the flag is no longer set it does not replace the other $null's with nothing.
This Gives the results as seen where you get a literal "$null" string returned.

It can be even more clearly seen here (i have replaced spaces with / to give a more detailed result)
First what you would expect (assume no 9th get)
//if (A $null B $get(9) C == A $remove(x,x) B $str(a,0) C) { echo TRUE } | else { echo FALSE } | echo $!v1 = $replace($v1,$chr(32),/) | echo $!v2 = $replace($v2,$chr(32),/)
TRUE
$v1 = A//B//C
$v2 = A//B//C

Now with the last $null returning value in a $iif
//if (A $null B $get(9) C == A $remove(x,x) B $iif(1,$str(a,0)) C) { echo TRUE } | else { echo FALSE } | echo $!v1 = $replace($v1,$chr(32),/) | echo $!v2 = $replace($v2,$chr(32),/)
FALSE
$v1 = A/$null/B/$null/C
$v2 = A/$null/B//C

And Lastly with a 2nd $null returning value in a $iff
//if (A $null B $iif(1,$get(9)) C == A $remove(x,x) B $str(a,0) C) { echo TRUE } | else { echo FALSE } | echo $!v1 = $replace($v1,$chr(32),/) | echo $!v2 = $replace($v2,$chr(32),/)
FALSE
$v1 = A/$null/B//C
$v2 = A//B//C

You well notice how the 2nd 3rd and 4th $null values have been replaced, however as I said above I believe they were replaced apon there identifieres returning them, rather than at the completion of the IF, (this is of course a speculative beleive, as I have no way of actually knowing if that is what occured to them, I did also note that even if one side of the /IF was just $null it would still work, whcih is different from what i showed if it was tried manually with no field there)

The Question I guess is if it is this flag problem, then should the IF protect the the value of the flag or should the $iif preserver the original value of it, it is saved if more complexe processing occurs with $+ or $+( ) etc involved, so is it just a small lapse in the IF code or the $iif code, Ill flip flop and now say I think it would be far simplier for the $iif code to simply restore the flag to the state it was in when it started, so now im saying its the $iif thats bugged.

For my next trick ill swear black is white and white is black and get run over on a zebra crossing, thankyou.