Forums Bug Reports $nick($chan,*) bug

Hello, I chat on a network that has superowners. Their user mode is the apostrophe. '

if ($nick isop $chan) returns $true
if($nick isowner $chan) returns $false

if ($nick($chan,NICKNAME,')) returns $true

So I use this method to tell if they are a superowner.

This is a selection fromt he nicklist popup.
$iif($nick($chan,$$1,'),$style(1)) Superowner

Puts a check mark preceeding Superowner if they are superowner.

Recently someone with a nickname that was just numbers has entered the room and they appear as a superowner using this method regardless of their user mode.

(the nick changes but the format is the same and the results are always the same)

NICKNAME: 65978736569070978

I figured out what happens is if I use:

$nick($chan,65978736569070978,') it returns the total number of SuperOwners in the room. The same as $nick($chan,0,').

It appears that this happens if the nick is more 11 or more digits.

Test it using . for owners instead of ' if you dont have a ' usermode. You will see what I am talking about. Check for a nickname of 10 digits, it will return $null. Check for 11 and it will give you the total number of nicks that have that usermode.

Thanks!

Well if you provide a number for that parameter then mIRC interprets that as meaning you want the nth nickname, so there's not much point fixing the 11 digit limit because of course you'd never have that many people in a channel at once.

mIRC doesn't expect a nickname to be all digits because all IRC RFCs define a nickname as having to start with a letter. While you can still find out if that nickname is a "superowner" by looping through $nick(#channel, n, '), I suggest you inform the admins of the network that breaking protocol for the sake of allowing people to use ridiculous nicknames like that is a really bad idea.

Even if you're maybe right, there still an issues here because i can reproduce his exemple with o,h,v mode and only if i use 11 digit.he can use the .pnick propriety as a workaround.

Hmm? My point is that a number for the second parameter represents the nth person in that channel with the given mode prefix. Obviously there won't ever be ten billion people on a channel. The pnick property doesn't affect anything, it'll just return the ten billionth person with their mode prefix.

If there's something specific to 11 digit numbers (other than the likely 32-bit wraparound issues) that's causing it to act as if 0 is given, then maybe there is a bug to fix if only to ensure it isn't part of some larger issue. But in any case this won't allow DJ_Sol to use numbers as nicknames in the $nick() identifier.

Yes, i agree, it's just that in his case, he have to used a loop with if $nick($chan,N,') == $1 or use the .pnick propriety

wouldn't it work if you did this:



From what I can tell, It return's $true if its correct and $false if not, and when its acting as '0' instead of the nick it returns the number of 's in the room.

I think this is a bug, allthough fixing it would break more scripts than it would help.

Oh, using

would break if he was that mode I guess, But it seems better to not show him as a ' any user that has that mode is likely to have a real nickname.

I'm guessing your using IRCX, which AFAIK would allow that type of nickname.

I guess we need input from Khaled.

What it returns is which # nick they are in that room with that usermode. So the 1st one in the list will return 1, the second 2 and so on.

If this were the case, then any number would return the total number of user's with this usermode in the channel. It only does this if the "nickname" is 0 or a nick is 11 digits or more.

All that means is that the number rolls over because it's too big. What's happening is that once a number is too large, it flips to negative and works its way back up to 0 and then into the positives again.

To test if it's the length of digits or the number itself...

(Change ! to whatever mode you're checking)

//echo -a $nick($chan,10000000000,!)
//echo -a $nick($chan,11111111111,!)

The first one will give an error and the second one will give the total number of users with the mode. Now, to prove that it's actually going into the negatives (rolled over once it's too large), try:

//echo -a $nick($chan,-5,!)

You'll see it treats all negatives as 0 as well because negative numbers aren't acceptable in this location.

So you can see that it's related the the maximum number that can be used in whatever calculation mIRC's doing and not the total number of numbers.

And, just because I felt like looking into it, it appears that the number is a signed 20-bit integer. This means that the number can be anything from -10737418239 to +10737418239.

//echo -a $nick($chan,10737418239,!)
//echo -a $nick($chan,10737418240,!)

The first gives the error, the second gives the total (because it's rolled over into negative).

As to why it's a signed 20-bit integer, I have no idea. That seems a little strange to me why it isn't at least using 16-bit, 24-bit, or 32-bit.

Btw, this is the same thing starbucks_mafia was saying.

That statement holds little value and isn't quite correct...

A "nickname of 11 digits" is not a nickname as defined by the IRC RFC (the protocol mIRC implements and follows), and therefore what you described simply does not exist in mIRC. It will just be a number.

So, knowing that you're dealing with a number (it's not a nickname), the mIRC documentation for $nick defines N as a number ranging from 0-N where N is the total number of users in the channel. An 11-digit number is therefore an invalid input to the identifier and has undefined results. You can't really blame mIRC for reacting oddly to bad input.

This goes back to starbucks' point... mIRC will only parse the N as a nickname if it is not a number (or not one of reasonable length, as you noticed)... mIRC made this design decision because the IRC RFC defined nicknames as beginning with a letter. The language makes this assumption in too many places to count, and so you won't get much further than $nick before you run into another number-related nickname issue. But the bottom line is that none of these would be bugs, since $nick(#,N) was not intended to be used the way you're using it.

Keep in mind that even if you still think this 11-digit length limit is relevant, your script would still fail if there was a nick of "65" in, say, an 80 user channel, because $nick(#,65) = 65th user in the channel... so the issue isn't really to do with 11 digit numbers at all, it's much more deep-rooted than that, and again, is directly related to the IRCd completely breaking the IRC spec. I think we can agree that there's really nothing at all that mIRC could do in a case like the one I just described, so fixing it for 11+ digit "nicknames" would only solve one of the many other cases that you would otherwise consider "a bug"-- why bother?

Well I agreed with Starbucks Mafia from the start and asked the developers to take a look at this thread. I just hoped mIRC could return a $null value instead of the total int he room.