Originally found by oss-fuzz (issue 525) in get_ansi_color using ubsan.
After a lot of analysis I'm 99% sure this isn't security relevant so
it's fine to handle this publicly.
The fix is mainly adding a function that does it right and use it
everywhere. This is harder than it seems because the strtol() family of
functions doesn't have the friendliest of interfaces.
Aside from get_ansi_color(), there were other pieces of code that used
the same (out*10+(*in-'0')) pattern, like the parse_size() and
parse_time_interval() functions, which are mostly used for settings.
Those are interesting cases, since they multiply the parsed number
(resulting in more overflows) and they write to a signed integer
parameter (which can accidentally make the uints negative without UB)
Thanks to Pascal Cuoq for enlightening me about the undefined behavior
of parse_size (and, in particular, the implementation-defined behavior
of one of the WIP versions of this commit, where something like signed
integer overflow happened, but it was legal). Also for writing
tis-interpreter, which is better than ubsan to verify these things.
If text is being entered and then the user presses the up arrow
followed by the down arrow, the expected behavior is to return to the
text being entered. Prior to this commit that was not the case.
Fixes#462
In glib v2.49.3, an optimization was made to eliminate certain
unnecessary wakeups. (The specific change was made in
e4ee3079c5afc3c1c3d2415f20c3e8605728f074). Before this change, the
first call to g_main_iteration would always complete immediately.
In Irssi, this effectively reversed the order of the main loop, causing
the reload_config check and the dirty_check to run *before* the first
blocking call to g_main_iteration.
With the new logic, the first g_main_iteration call now blocks,
preventing the screen from being refreshed until the user starts typing
or a timer goes off. (It also delays processing of SIGHUP, but I
expect that is not a common situation.)
This commit reorders the main loop to wait at the end of the loop,
rather than the beginning, addressing the problem.
(This closes Debian bug #856201.)
The script unloading code originally worked like this:
1. Destroy package
2. Emit 'script destroyed' signal
3. Unhook script's signal handlers
If a script added a 'script destroyed' signal handler, unloading
that script would cause the 'script destroyed' signal to be sent to the
(already destroyed) package. This would cause a script error, which would
trigger a script unload, which would start the whole process over again,
until we run out of heap or stack space and segfault.
This commit simply reorders the operations so that the 'script destroyed'
signal is sent *after* the script is fully destroyed.
PR #453 forces the user to quote the filenames given to /DCC commands
when they contain spaces but the autoget functionality didn't get
updated so the filename was always passed without quotes.
Closes#656.
