The symptom for this one is randomly getting lines split before the last
word, even if there's no need for splitting. Also, this function is only
reached if recode is on, and iconv failed (for example, due to an
incorrect source charset). Thanks to vague for finding this and
providing valgrind logs.
The loop that looks for spaces tried to read backwards from the end of
the current line, with the end being determined by len. Assuming
strsplit_len() with len=400, this meant accessing str[399] in the first
iteration. For strings that don't need splitting, this means an invalid
read always.
If that invalid read happens to hit garbage that has a space character,
(len - offset) points after the end of string, which isn't a problem for
g_strndup() since it stops at the first null, and no splitting happens.
If the garbage doesn't have any spaces, it splits by the last word.
This commit avoids that loop entirely if (remaining_len > len). It also
changes the way it iterates over the string to be much less confusing.
Try to split long lines on spaces to avoid words being splitted. This
can be turned off with the option `split_line_on_space'. The code
assumes that the terminal encoding has ASCII spaces.
This commit adds handling of long IRC messages to the core. In contrast
to the `splitlong.pl' plugin, multi-byte encoded and recoded messages
are properly split.
To allow for this, a new function has been added to the server struct:
`split_message'. `split_message' returns a string array with the message
splitted to substrings of a length that the server can handle. If a
protocol module doesn't have any limit, it can simply return a singleton
array with a copy of the message.
The `MSG' chat command now calls `split_message' before `send_message',
and emits `message own_public' / `message own_private' with each
substring, so that the string splitting will be visible in the UI.
`split_message' in the IRC module uses `recode_split' which in turn uses
iconv to properly split multi-byte encoded (and recoded) messages.
This code is used, for example, when /set expand_escapes on.
I can't reproduce crashes but I can reproduce garbage if I type a\1.
bug #775
git-svn-id: file:///var/www/svn.irssi.org/SVN/irssi/trunk@5195 dbcabf3a-b0e7-0310-adc4-f8d773084564
This makes /set server_reconnect_time = 10min fail
instead of setting the time to 0.
git-svn-id: file:///var/www/svn.irssi.org/SVN/irssi/trunk@5057 dbcabf3a-b0e7-0310-adc4-f8d773084564
returned as hours*7.. which also means I calculated the max. return value of
over 1 year wrong. It's actually 24 days, but it's hopefully enough. Removed
"weeks" unit to discourage usage of large values..
git-svn-id: http://svn.irssi.org/repos/irssi/trunk@3143 dbcabf3a-b0e7-0310-adc4-f8d773084564
automatic converter to these settings later. Meanwhile you CVS users can
fix your config files yourself :)
Time settings allow using "days", "hours", "minutes", "seconds" and
"milliseconds" or several of their abbreviations. For example "5d 4h
5msecs".
Size settings allow using "gbytes", "mbytes", "kbytes" and "bytes" or their
abbrevations. For example "5MB".
Level settings are currently handled pretty much the way they were before.
git-svn-id: http://svn.irssi.org/repos/irssi/trunk@3080 dbcabf3a-b0e7-0310-adc4-f8d773084564
a few changes to DCC so that it should be possible to send >4GB files.
DCC protocol uses 32bit "n bytes transferred" notifications, so I had to
bend the protocol a bit to allow 64bit files by truncating the value to
lowest 32bits. I'm not sure how other clients handle those notifications,
but irssi uses it only to figure out when the DCC SEND transfer is complete,
so it's quite safe to assume that if we've managed to write() all the bytes
and we receive the last 32bit of file size, it means the total file size
instead of the total - (n+1)*4GB.
git-svn-id: http://svn.irssi.org/repos/irssi/trunk@3018 dbcabf3a-b0e7-0310-adc4-f8d773084564