This ii behavior is surprising.
user$ ruby -e "puts 'A'*512+'B'*20" > server/channel/in
user$ tail -f server/channel/out
1533032971 -!- nick(~nick_AT_1.2.3.4) has joined #channel
1533033745 <nick> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
1533033745 <nick> BBBBBBBBBBBBBBBBBBBB
Consider this,
user$ ruby -e "puts '/privmsg #myfriend789 That party was great...' + 'A'*467+'/l ipstickgirl gave really great -- omg everyone is totally reading this'" > server/channel/in
Meanwhile...
[07:07] == nick [~nick_AT_1.2.3.4] has left #channel ["ipstickgirl gave really great -- omg everyone is totally reading this"]
The relevant function is read_line
static int
read_line(int fd, char *buf, size_t bufsiz)
{
size_t i = 0;
char c = '\0';
do {
if (read(fd, &c, sizeof(char)) != sizeof(char))
return -1;
buf[i++] = c;
} while (c != '\n' && i < bufsiz);
buf[i - 1] = '\0'; /* eliminates '\n' */
return 0;
}
One idea is to use a large buffer with size IRC_MSG_MAX*5 then terminate the program if read_line fails to find a linefeed. Later in proc_channels_input we can decide not to send the message if it's larger than IRC_MSG_MAX.
The obvious but complex option is too add buffering.
--
burrows
Received on Tue Jul 31 2018 - 13:24:53 CEST