>Well, one would hope that anyone running "xlock" would be running "xlockmore"
>guised as "xlock", since every version of "xlockmore" since 1.14 (current is
>3.6) has not only supported NetBSD, but it's also smart enough to run as the
>invoking user all the time, only becoming root as is necessary to read the
>shadow password file when unlocking.

Hmm.. this xlock was from a binary distribution. What tells (among other):

        xlock.c 3.0 95/06/28 xlockmore

so the "who knows" was probably a cheap shot at an innocent well made
util. Sorry about that. These hangs are just so annoying. BTW: has
anyone thought of using the GCC bounds checking patches to debug the
kernel? Has anyone on this list used the patches? How well does the
checking catch problems? I've used purify and it's pretty good (for
userland applications), and it works by instrumenting object code. In
principle checking built into the compiler can work much better. A bit
off topic perhaps..