I went through and made this patch independently before I came upon this open bug. Note: The misuse of ctype(3) can lead to undefined behaviour, including crashes and/or exposure of secrets from reading before the beginning of a ctype table in memory, and the problem is not limited to NetBSD. From the commit message I wrote:

The ctype(3) functions take arguments of type int that are either

(a) EOF, or
(b) unsigned char values, {0, 1, 2, ..., 255} if char is 8-bit.

Passing values of type char, on platforms where it is signed, can go
wrong -- negative values may be confused with EOF (typically -1) or
may lead to undefined behaviour ranging in practice from returning
garbage data (possibly out of an adjacent buffer in memory that may
contain secrets) to crashing with SIGSEGV (if the page preceding the
ctype table is unmapped).

The ctype(3) functions can't themselves convert to unsigned char
because then they would give the wrong answers for EOF, for use with
functions like getchar and fgetc; the user has to cast char to
unsigned char.

It is possible, in some cases, to prove that the input always
actually lies in {0, 1, 2, ..., 127}, so the conversion to unsigned
char is not necessary. I didn't check whether this was the case --
it's safer to just adopt the habit of always casting char to unsigned
char first before using the ctype(3) macros, which satisfies a
compiler warning on some systems designed to detect this class of
application errors at compile-time.