There is a problem is Problem with masks in $mask $address and /ignore when the user part of the fulladdress is longuer than 10 chars.

Examples:

var %w = nick!verylonguser@hostname
echo $mask(%w,0)
>> *!rylonguser@hostname

echo $mask(%w,1)
>> *!*ylonguser@hostname

echo $mask(%w,5)
>> nick!rylonguser@hostname

I would expect $mask(%w,5) to at least return the correct fulladdress.

I believe this is because the IRC RFC states that a 'user' string can have a max length of 9 character. Add to that the ~ prefix that is often used when no identd response is received and you end up with a max length of 10 characters.

Personally I don't know of any IRC server which allow you to have a user name of more than 9 chars, so I can't test this behaviour.

If it can't, mIRC should perhaps be able to interpret longer user strings. However, I feel ambivalent about it.

But the rfc also says:
While the maximum length is limited to nine characters, clients SHOULD accept longer strings as they may become used in future evolutions of the protocol.

It's just the $mask() alias that is "broken" (I think both $address() and /ignore use this function internally), since one can manually add a perfectly functional ignore with the full "user".

Are you quoting or paraphrasing the RFC? "While the maximum length is limited to nine characters..." is not located in RFC1459. In addition, I don't see where this is mentioned even in another wording.

I guess if there exists a server where this becomes problematic it should be fixed. The question is, are you actually testing this on a server where you could run into this "problem"? If not, it's not a real problem.

He's probably refering to http://tools.ietf.org/html/rfc2812#section-1.2.1

Yes rfc2812
"1.2.1 Users"

What server is this failing on, though?

I'm testing some scripts on a french server. (irc.voila.fr)
It's not a server I'm usually connecting to, but their system is a good subject of study for some of my scripts.

If you want to test it, unfortunately the server requires authentication with a unique key. Key that must be retrieved from they web server.

Their server automatically rewrites the "user" part of the fulladdress: !guest@ for non-registered nicks, and several variations (based on the level of confidentiality) for registered users. It's the second type that breaks the rule of max 9 (10) chars of length.

Here is an example of a fulladdress (one of their ircops):
artio!000Znowhere@520.681....

If I recall correctly, at one time mIRC did store more than nine characters for the user string, however due to bug reports relating to that behaviour mIRC was changed to comply with the maximum length. I can't remember the reason for the original bug report unfortunately apart from the fact that there were side-effects on some IRC networks when the maximum length was not enforced.

Perhaps a good compromise would be to add '*' if it's being truncated.