Handle messages larger than IRC_INITIAL_BUFSIZE

[ctaveras]

Fixes ​https://developer.pidgin.im/ticket/12562.

[Robby]

Any reason you didn't attach it to the existing ticket? :)

[ctaveras]

I was following these instructions: ​https://developer.pidgin.im/wiki/TipsForPatchSubmissions

Perhaps I was following them a little too closely? From the instructions, it seems like new patches require a new ticket categorized as "patch" and not "new defect".

[Robby]

Ticket types can be changed. Maybe that Wiki page needs to changed to take existing tickets into account.

Not to worry. :-)

[QuLogic]

You probably want to limit inbuf to some large, but not unreasonable value. Also, the while (1) seems troublesome. On a fast enough connection, it would probably block the UI.

[ctaveras]

Attaching patch to irc.c

[ctaveras]

I've uploaded a new patch taking into account QuLogic's feedback. But it's conceivable that an IRC server with a sufficiently large MOTD could trigger the same behavior, which makes this commit a stop-gap measure. What we really need is a way to ensure the input callback gets called on the next iteration of the loop even if the socket isn't drained of pending data on the current iteration. Perhaps something as simple as scheduling it from the callback itself? I haven't had time to look at it further.