[Pidgin] #15090: freenode's new +q numeric (728) is unrecognized

[Pidgin]

#15090: freenode's new +q numeric (728) is unrecognized
---------------------+------------------------------------------------------
 Reporter:  marienz  |        Owner:  elb
     Type:  defect   |       Status:  new
Milestone:           |    Component:  IRC
  Version:  2.10.3   |   Resolution:     
 Keywords:           |  
---------------------+------------------------------------------------------

Comment(by marienz):

 My apologies for missing the MOTD option, I had overlooked that in the UI.
 No need for a /motd, in my opinion, as a more GUI-oriented user than me
 would probably have found that.

 I understand these changes happen quickly enough for them to be a pain for
 client developers (as you pointed out irssi doesn't handle the +q one
 great either, which is an annoyance to me), I just wanted to point out
 "networks like to change their made-up numerics more often than their ops
 change underwear" exaggerates slightly.

 Thanks for the patch. I've tested it a bit and it is an improvement (and
 I'm assuming other libpurple-based clients will pick this up without
 needing further work on their end?). Two points though (on elb's patch, I
 noticed the second patch only after I'd started writing this comment, I'll
 go look at it now):

 I'm fairly certain the null check in the loop should be against end, not
 cur. With the check as it is I can get pidgin to crash by doing "/quote
 info", which ends up calling g_strndup(cur, end - cur) with end null, and
 glib fails the resulting huge allocation. If I could get the server to
 send me an even shorter message the loop would call strchr on NULL + 1,
 which wouldn't be very healthy either.

 I think it'd be slightly prettier to only report the arguments after the
 channel name to the user. That is: "tmp = purple_utf8_salvage(end + 1);"
 (which I believe is safe with the null check fixed, although it could
 theoretically log empty messages). This removes: the prefix (which should
 be the source server, which users will not care about), the numeric itself
 (which very few users will recognize), the 2nd argument (which is normally
 our own nick, as RFC1459 says this must be "the target" of the message),
 and the third argument, which we've just made sure is the name of the
 conversation the message appears in. So I believe those are all redundant.

 A moderately visible unsupported numeric this exposes is 328 aka
 RPL_CHANNELURL: if you join #pidgin it'll now show you
 ":http://pidgin.im/".

 It is unfortunate this still misses 435 aka "Cannot change nickname while
 banned on channel", but without a server/status window that is probably
 not fixable cleanly. Shall I file a fresh bug on that, as it's probably
 worth throwing a dialog up for similar to the "The nickname ... is already
 being used." one?

-- 
Ticket URL: <http://developer.pidgin.im/ticket/15090#comment:5>
Pidgin <http://pidgin.im>
Pidgin