Forums Bug Reports 6 more bugs

1. If an IRC server uses text decoration control codes on the network name in its 001 "Welcome to the Green Network, YourNick" banner (example: ^U^B^09,03Green^O), mIRC's connection tip will be "You have connected to 0903Green Network as Nick". (Note: I didn't leave out the comma. It strangely strips control code characters and even the , within K control code sequences -- just not K's digits.)

2. $mid(string,0,1) logically should return null but returns the same character as $mid(string,1,1).

3. /.say ignores its . and echos to the current window anyway.

4. If a line begins with ^O, and if that line is CTRL-copied from its very start with the mouse, its leading ^O is stripped. (If copying multiple lines, only the first is affected.) Note: this may seem moot, but it's only visually moot; from the standpoint of wanting to grab all control codes, you're still losing one.

5. mIRC splits long channel/query messages too early if an outgoing line's nick/ident/hostname/etc. strings are themselves short. (This is much too hard to illustrate here, so please look at http://pastehtml.com/raw/bw24jqljz.html, where I've prepared horizontally-scrollable debug output examples -- and note that this URL won't blast you with ads or popups.)

6. I'm uncertain why mIRC behaves this way, but it allows an insane amount of "horseplay" with the / command prefix (this may or may not be the actual bug -- please keep reading). For example, where you would expect only /me, //me, /.me, or //.me to work, all of the following actually work:


As strange as all that is, the same behavior does not apply to the alternate command prefix (ALT-O > Other). For example, if I set the alternate command prefix to \ then:


The reason I noticed all of this was because I'm writing an ON INPUT event which I prefer to be 100% "transparent" to every possible permutation of user-typed commands (i.e., so it will honor the user's request for evaluation if he uses // or //. and so it will honor his request for silence if he types /. or //.).

Needless to say, when I discovered just how many permutations mIRC allows, that ideal crumbled -- I'm just not up to the regexp wizardry this would require.

Still, I thought I would report it for one reason: one of the above is a bug (either that the built-in / prefix allows so much mutation, or that the alternate command prefix doesn't). Since one must be the "intended" way, that has to mean the other is broken.

1) It would be a good idea to provide a server you are testing this on.

2) It's not a bug, rather a feature, 0 is invalid for the second parameter so mirc use a default value of 1.

3) This is probably intended behavior but I agree.

4) I reported a similar bug recently, https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/234808/page/2#Post234808 but it seems to be intentional.

I can't. I found this bug while locally configuring/testing an ircd. But if you want to reproduce it for yourself:

a) unpack http://ircd.bircd.org/bewareircd-win32.zip to a new temporary folder (for linux: http://ircd.bircd.org/bewareircd-linux.tar.gz) (note: this IRCd is open source and stand-alone: it has no installation process, makes no registry modifications, and modifies no files outside its own folder).
b) open bircd.ini and paste this line at the top: RPL001=Welcome to the 09,03Green IRC network, %s (%s)
c) save changes to bircd.ini and then execute bircd.exe ("bircd" in linux)
d) in mIRC, /timertest 1 5 /server -m 127.0.0.1:6667 (use the timer delay to unfocus mIRC's window before it connects, so tips will appear)
e) you'll see the bug when it connects
f) execute "bircd signal stop", then delete temp folder

Update: When I previously noticed this bug, the ircd was configured to send a 005 NETWORK= token. Out of the box, using the instructions above, no 005 NETWORK= token is sent. In that case, not only does the network name appear as 0903Green in mIRC's conenct tip, but it also appears as 0903Green in the switchbar button, status window title bar, and $network. So, it appears mIRC mainly relies on 005 NETWORK= for knowledge of a network's name (if it is present), but that the tip always relies on 001's mention of the network name, even when 005 NETWORK= isn't present. Either way... the same problem remains: mIRC strips control codes, including ^K control codes, but not the digits in ^K code sequences.


Hm, however, isn't it customary with any programming language that invalid input shall never return valid output? For instance, $left(abc,0) returns null, not "a". So why should $mid(abc,0,1) return "a", and not null?

Not the best example. 0 isn't exactly invalid there. You're just saying to display 0 characters from the left. That's what it's doing by being $null, so $null is a valid output rather than an invalid one. That being said, I do think $mid() should probably display $null (as a valid output, not because 0 is invalid). That would let you loop through from positive to negative in a more accurate way if you needed to... $mid(string,-1,1) = g, $mid(string,0,1) = $null, $mid(string,1,1) = s.

As far as #6, I think that's also by design. It ignores 1-2 additional sequential command characters (including . and treating // as a single character) that appear before the command name if provided. Although I'm sure it's by design, I don't think it is really all that necessary. Especially if it doesn't treat alternate command characters the same way. So although I think it's by design, I do think it would be better to not ignore additional characters.

And, as mentioned above, 3 and 4 appear to be by design as well. I'm sure /say could support . without a problem, so that could probably be added. Though I personally stick to /msg instead of /say for scripting. And when the first character in a line is Ctrl-O, it's basically the same as not having that character there. mIRC's just ignoring an unnecessary character. I can see potential reasons for wanting that character to appear, but in almost all situations, the character is not needed. But to support the rare cases where it might be needed and because it wouldn't hurt anything, I think including it would be a good option.

6 is not a bug, it's part of the parser. mIRC's parser is extremely lenient just about everywhere. It's your responsibility to do what is correct. The parser has to handle things like:



Note that the last example in the above script actually would expand to "/./msg", which is part of the reason mIRC is so lenient about prefixes.

Note that '/' is a special command prefix character, even when the alternate command prefix is used. / continues to work in scripts, and / is always parsed within a /command prefix, regardless of the command prefix character setting. Example, set it to \ and do:

//echo -a hi <- still works
\/echo -a hi <- works too

However, since the alternate prefix only affects the editbox, mIRC can enforce a max of two \'s. This cannot be done for / because of the quirks of script processing discussed above.