Forums Bug Reports CMODE +y bug

And is there a RESERVEDMODES=yw in CR, and does mIRC understand it? The answer is no. How is mIRC to know it should do nothing with those modes? It doesn't. Why is that mIRC's fault? It isn't. And why didn't I read the CR manual? Because as far as I know there is no freely downloadable version, and there is no way in hell I'm going to pay so that I can read it.

Because as far as I know there is no freely downloadable version, and there is no way in hell I'm going to pay so that I can read it.

It costs $0 and 0c. http://irc.bigpond.com/manual/

And is there a RESERVEDMODES=yw in CR

ConferenceRoom 2.0.2f-SEC abcdefghijkmnopqrstwxyzABCLIMORX abcdeijklmnopqrstuvzACJLMNORU
SMARTHELP WALLCHOPS TUNL WHISPER KNOCK PROP LANG FIELD SM TUNL CHANTYPES=# PREFIX=(ovu)@+- NICKLEN=30 MODES=12 SILENCE=10
CHANMODES=bouv,k,lOMN,cdejimnpqrstzAJLRU WATCH=256 KICKLEN=64 MAXBANS=75 MAXCHANNELS=12 SSL FLG=wEsekpv,5

Where?

I said "is there" not "there is"

It's still irrelevant anyway - if, as you say, mIRC doesn't understand RESERVEDMODES then it's pointless having it there purely for this exercise. The fact still remains that there is no valid explanation as to why someone would expect performance from a mode that has no documented function and is indeed marked N/A in the HelpServ reference. So why is +y even being used and who really cares what it does? It's been there for, like 6 - 7 years and this is the first time it's ever raised a mention.

This isnt the only server or IRCd to do it. Global servers also do this where if you do /mode #someroom +o NaKI, it will change the case of it.

hehe, Well that is perfect evidence that it is mIRC that is at fault but don't tell codemastr, he thinks that just because it doesn't happen on Unreal means that it's the fault of other IRCd's.

If this mode is not meant to be used, it should be removed or at least made Oper-only. And yes, i think it's IRCd's fault, too.

So two IRCd's made my two seperate organisations are responsible for a foul-up in one programme? That makes no sense at all. Especially since the modes used on each IRCd are different. Think before speaking.

Wow you mean two IRCds have the same bug? Thats unheard of! Oh wait, no it isn't, it happens with almost every bug ever found in IRCds.

Well common sense dictates that one associates the problem with the common cause, that being mIRC's adverse response to the case change on mode change. If the problem is happening on two entirely different brands of IRCd then Khaled should build some resistance into mIRC to prevent the case change happening. Lets not forget here that +o is an op/deop mode, not a case change mode, that said you barely had a valid arguement with +yu in the case of CR. In the case of whatever other IRCd affects mIRC this way, you have absolutely no valid argument at all.

While I am on the subject, I tried this issue in X Chat, Klient, Bersirc and kVirc. I even telnetted for what it was worth (even though there's no nicklist in DOS I was still able to see the full raw event). No other chat client that I know of is affected by this - only mIRC. The bug is therefore in mIRC.

Give me a server where I can test it and I assure you I can find other clients that are affected.

hehe It's funny how when I prove something beyond reasonable doubt that I am being milked for information. Try Webmaster's own network. As for the other IRCd, I don't know what network the other poster here was talking about, though I have the nouse to just simply believe him.

For the record I don't dispute that there may be other clients that react the way mIRC does. I'm just saying that those that I tested didn't do it for me. Either way, I am satisfied that mIRC is at fault here. In closing, it would be interesting to know if you'd be so vocal on this issue if Unreal did the same thing.

I tried webmaster's network, however they require a registered nick to create a channel, and to register a nick requires me to give my email, and thats not gonna happen. Anyway, I don't see what Unreal has to do with this. When unreal has a problem, I don't deny that it exists I say "thanks for finding that, I'll go and try to fix it" as I am currently doing on a couple of bugs that have been reported. Maybe you're too used to the MS theory of bugs, where they believe it is better to deny the bugs exist rather than actually fix them, however not everyone believes such things.

There are certain things not specifically mentioned in RFC1459 that are defacto standards, one of these is validation. For example, if you type /mode #chan +b blah*. Thats totally legal, however every server I've ever seen will translate this to blah*!*@*. Does this mean a server that doesn't do this is breaking a standard? No, but it does mean it isn't going along with a "generally accepted standard." The same holds true for things like +o/+v. If I send "+v BLAH" and the user's nickname is "blah" it is generally accepted that the server will translate the "+v BLAH" to "+v blah". Again, it's not necessarily required, however if everyone except 1-2 servers do it that way, well then imho it is the fault of the server, not of the client.

Maybe you're too used to the MS theory of bugs, where they believe it is better to deny the bugs exist rather than actually fix them

If you mean the Micro$oft that fixes more bugs and more quickly than any other software vendor known to modern man then perhaps you are right.

As for testing your urban myth that the case bug is the fault of an IRCd rather than mIRC, I cannot help there much because I only know of two networks that use CR (as I don't hop around as much as I used to) they being Bigpond (which doesn't currently allow user-created channels) and Webnet, where people who try to prove a point for the sake of trying to be right when they are wrong are too lazy to register nicknames. As for the second IRCd which affects mIRC this way, I do not know where that is. One thing is for sure, as I have stated, mIRC seems to object to being force-fed a changed case for inappropriately used modes therefore there is a bug in mIRC, as the original poster suggested.

You mean like the WinXP SP1 causes performance slowdowns bug that effects tens of thousands of users yet Microsoft refuses to admit the problem even exists?

In any case I'm not arguing with you anymore, you're argument now revolves around the statement "I'm right because I say I'm right" so there is no point in arguing this further. When I try and offer reasons why it isn't mIRC's fault, you just ignore that and go back to "it only effects mIRC, therefore mIRC is broken". Did it ever occur to you perhaps mIRC is the only one that behaves correctly and that all other clients could be wrong?

Your argument would be valid if you call an obvious bug a correct operation.

Guess what, i tried it with Bahamut, ircu, Unreal, Ultimate, Hybrid and tons of different IRCds. None of them is affected by this - only CR and "Global" (whatever it is). The bug is therefore in those two IRCds.

Maybe instead of saying "it only happens with mIRC" you should say "it only happens with CR"...?

Maybe instead of saying "it only happens with mIRC" you should say "it only happens with CR"...?

Because it doesn't only happen with CR.

Well I've got about 150 different IRCds on my machine, I've never heard of one called "Global". The only one close I know of is called GlobalIRC-d (Gircd for short) which is a Mac-only IRCd. To my knowledge, this IRCd hasn't been developed since 1999 and it is known to be one of the buggiest IRCds in existence.

What's that got to do with me? I didn't mention an IRCd called Global or anything else. Why don't you go back to the beginning and read again from the start.