A change in GLib 2.63 broke some assumptions in Irssi that the null-byte NUL / U+0000 is a valid Unicode character. This would occur when the user types Ctrl+Space. As a result, the input loop never manages to process the NUL-byte (and any other user input that follows, ever).

This affects all versions of Irssi as soon as your system is updated to this GLib version.

GLib issued a statement that this needs to be changed in Irssi: https://gitlab.gnome.org/GNOME/glib/-/issues/2093

A patch for Irssi 1.2.2 is available at https://github.com/irssi/irssi/releases/download/1.2.2/glib-2-63.patch

original bug report follows

pressing ctrl+space freezes irssi. i believe this is due to irssi being unable to handle NUL (\0).

hypothesis

computers let the user enter control characters by using ctrl and a letter, shown using a caret like ^a. when one uses ctrl+2, the code ^@ is generated, but on some systems, ctrl+space also produces ^@.

the ascii characters next to the alphabet are mapped to control charaters: ^@ is \0, ^[ is \1, ^| is \2, etc. this means that ctrl+space produces \0.

i don't know why irssi crashes on a NUL byte, but i'd blindly guess its because of null-terminated strings. yitz on #irssi is debugging.

affected builds

i've asked around a few networks and it affects arm, x86, x64, many shell/terms, debian, alpine, void, arch, ubuntu... (so musl and glibc).

affects irssi 1.0 to 1.2.2, more details below.

how to reproduce

1. press ctrl+space
2. irssi is now frozen

ctrl+2 might work on some keyboard layouts.

tested configurations

crash	term	shell	irssi version
yes	urxvt	fish	1.2.2
yes	guake	zsh	1.0.7-1
no	roxterm	zsh?	1.0.7-1
yes	termux (?)	zsh	1.2.2
yes	xfce4-term	bash	1.2.2-1
yes	urxvt	zsh	1.2.2
no	mac's iterm	idk	1.1.1