Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The order of operators are different from the initial test, so this increases
the code coverage in wee-calc.c.
|
|
|
|
|
|
|
|
"revscr:"
|
|
"modifier:name,data,string" (issue #60)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"calc:..." (issue #997)
|
|
It is possible to trigger a segmentation fault while processing
an evaluation of repeating string. On a Linux 64 bit system,
enter this (or adjust arguments for 32 bit accordingly):
/eval -n ${repeat:1073741824,----}
It will overflow an integer calculation because int instead of
size_t is used. Proper check of int limitations fixes this issue.
I haven't changed this specific piece of code to size_t because it
would crash in other parts of the code tree instead. For now, int
is a limitating factor when it comes to strings (and should be
enough for sane use cases).
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
|
|
(issue #1394)
|
|
#1394)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
irc_message_parse_to_hashtable
|
|
|
|
|
|
|
|
|
|
|
|
argument (closes #1296)
|
|
This fixes a compilation error on FreeBSD.
|
|
|
|
|
|
|
|
|
|
|
|
(issue #928)
|
|
The problem is that on 32-bit arch (like GNU/Hurd), the number 42000000000000
is converted to 42000000000000L in Python, which is causing troubles in other
languages like Perl.
The fix is to use a smaller number. Such large size for function
string_format_size is tested in the C++ test suite anyway.
|
|
|