Opened 5 years ago
Last modified 5 years ago
#15896 new patch
Handle messages larger than IRC_INITIAL_BUFSIZE
Reported by: | ctaveras | Owned by: | elb |
---|---|---|---|
Milestone: | Component: | IRC | |
Version: | 2.10.8 | Keywords: | SSL inspircd packets gnutls openssl |
Cc: | elb, Stmeter |
Description
Attachments (1)
Change History (6)
comment:1 Changed 5 years ago by Robby
comment:2 Changed 5 years ago by 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".
comment:3 Changed 5 years ago by Robby
Ticket types can be changed. Maybe that Wiki page needs to changed to take existing tickets into account.
Not to worry. :-)
comment:4 Changed 5 years ago by 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.
comment:5 Changed 5 years ago by 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.
Any reason you didn't attach it to the existing ticket? :)