Perl sucks and kills the whole process when there's a version mismatch
in Perl_xs_handshake(). Our atexit handler catches the exit and
deinitializes the terminal, removing the error.
This commit uses the 'quitting' global variable which is set when irssi
is voluntarily quitting, and avoids sending TI_rmcup, which restores the
original screen and makes the error invisible.
This avoids the use of g_list_find() to find if a match was already
added to the list of results, by checking the last two added matches
instead.
Checking just the last match isn't enough because a NULL match is added
as a separator (shown as -- in the UI)
This applies to "/lastlog" with no filters (or with filters that don't
filter a lot) and with large amounts of text in the scrollback.
Test case:
/exec seq 1 500000
/lastlog -file log.txt
Thanks to morning for reporting this.
The warning itself:
>warning: comparison between pointer and zero character constant [-Wpointer-compare]
Harmless stuff as far as I can tell.
The fix adds a null check that probably isn't needed. The old code that
compared against '\0' worked a lot like a null check so it makes sense
to keep that, while also adding the intended check for empty string.
This was visible with "/dcc close send a" showing an empty filename.
The equivalent for get didn't show the filename in the format string.
Add a more detailed paragraph about service bots
Fixes#699
I would like to add another paragraph about how freenode is
broken and spits at you the whole list instead of empty list
if you attempt to use network side filtering......
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.
