fix buffer overflow when handling long composed input
To reproduce the issue:
"
If you already have the multi-key enabled on your system, then add this line
to your ~/.XCompose file:
[...]
<question> <T> <E> <S> <T> <question> :
"1234567890123456789012345678901234567890123456789012345678901234567890"
"
Reported by and an initial patch by Andy Gozas <andy@gozas.me>, thanks!
Adapted the patch, for now st (like dmenu) handles a fixed amount of composed
characters, or otherwise ignores it. This is done for simplicity sake.
Ref.
https://git.suckless.org/st/commit/e5e959835b195c023d1f685ef4dbbcfc3b5120b2.html
the array is not accessed outside of base64dec() so it makes sense to
limit it's scope to the related function. the static-storage duration of
the array is kept intact.
this also removes unnecessary explicit zeroing from the start and end of
the array. anything that wasn't explicitly zero-ed will now be
implicitly zero-ed instead.
the validity of the new array can be easily confirmed via running this
trivial loop:
for (int i = 0; i < 255; ++i)
assert(base64_digits[i] == base64_digits_old[i]);
lastly, as pointed out by Roberto, the array needs to have 256 elements
in order to able access it as any unsigned char as an index; the
previous array had 255.
however, this array will only be accessed at indexes which are
isprint() || '=' (see `base64dec_getc()`), so reducing the size of the
array to the highest printable ascii char (127 AFAIK) + 1 might also be
a valid strategy.
ref. https://git.suckless.org/st/commit/ef0551932fb162f907b40185d2f48c3b497708ee.html
from the XmbTextListToTextProperty(3) man page:
"If insufficient memory is available for the new value string, the functions
return XNoMemory. If the current locale is not supported, the functions return
XLocaleNotSupported. In both of these error cases, the functions do not set
text_prop_return."
Reported by Steffen Nurpmeso <steffen@sdaoden.eu>, thanks!
Ref. https://git.suckless.org/st/commit/2f6e597ed871cff91c627850d03152cae5f45779.html
The bits of uint signal in an XKeyEvent which concern the key group (keyboard
layout) are bits 13 and 14, as documented here:
https://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html#Groups_and_Shift_Levels
In the older version, only bit 13 was marked as part of XK_SWITCH_MOD, this
causes issues for users who have more than two keymaps. The 14th bit is not
in ignoremod, key sequences are not caught by match(), if they switch to a third
or fourth keyboard.
This reverts commit e8392b282c2eaa28725241a9612804fb55113da4.
There is currently a bug in older ncurses versions (like on OpenBSD) where a
fix for a bug with REP is not backported yet. Most likely in tty/tty_update.c:
Noticed while using lynx (which uses ncurses/curses).
To reproduce using lynx: echo "Z0000000" | lynx -stdin
or using the program:
int
main(void)
{
WINDOW *win;
win = initscr();
printw("Z0000000");
refresh();
sleep(5);
return 0;
}
This prints "ZZZZZZZ" (incorrectly).
