to zero, and returns zero (no error).
v_event_get() calls v_event_append(), but since e_len is zero, nothing
is put in gp->i_event[] and gp->i_cnt is not incremented. But the code
goes on to use gp->i_event[gp->i_next], even though that element
wasn't set.

Another consequence is that v_event_get() calls QREM(1) before returning
(line 670 of common/key.c), but since i_cnt was likely zero, QREM()'s
decrement may wrap i_cnt to a huge unsigned.

Since i_cnt can now incorrectly be > 0, v_key()'s next call to
v_event_get() can incorrectly return whatever happened to be in
gp->i_event[0], and if it's not valid, the abort() in v_event_err()
may be called.

You can see the abort() by setting LANG to C.UTF-8, running
nvi, and typing a pair of characters with high bits set that
aren't legal utf8. On my keyboard, I can type option-u option-i,
which generates 0xf5 0xe9.

Perhaps this can be fixed by 1) goto retry in v_event_get() if
gp->scr_event() returns an E_STRING with e_len =3D=3D 0, and 2) set
clp->skip =3D 0 in cl_event() on Invalid input, to reset the UTF-8
parsing state. But I do not understand the code well enough to be
sure.

--=20
You are receiving this mail because:
You are the assignee for the bug.=