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@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@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
