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.)
Commit 6300dfec7 removed the option to disable SSL support from the
configure script since it became a requirement, but it also removed the
use of pkg-config for finding the OpenSSL library and its dependencies.
This had the unfortunate consequence of breaking the correct detection
of library flags in many static linking scenarios. In some cases, for
example, OpenSSL might have been built with zlib, which requires `-lz`
to be passed to the linker when doing a static link of the irssi
executable. Thus, pkg-config becomes an invaluable tool in such
situations, since no guessing work is needed as the OpenSSL .pc file
provides all the necessary flags.
So, this commit re-inserts the PKG_CHECK_MODULES macro in the configure
script when looking for OpenSSL. The test using AC_CHECK_LIB remains,
but only as a last resort in case the one using pkg-config fails.
Also, because the macro AM_PATH_GLIB_2_0 contains an unconditional call
to PKG_PROG_PKG_CONFIG, the OpenSSL checks are moved so that they come
after the Glib ones in order to avoid doubly checking for the pkg-config
binary (PKG_CHECK_MODULES skips that check if it has been performed
before, but PKG_PROG_PKG_CONFIG does not).
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.
