since this interface is rarely used, it's probably best to lean
towards keeping code size down anyway. one-character needles will
still be found immediately by the initial wcschr call anyway.

if the buffer is too short, at least return a partial string. this is
helpful if the caller is lazy and does not check for failure. care is
taken to avoid writing anything if the buffer length is zero, and to
always null-terminate when the buffer length is non-zero.

bug report and solution by Richard Pennington

bug report and solution by Richard Pennington

these are mostly untested and adapted directly from corresponding byte
string functions and similar.

programs that use this tend to horribly botch international text
support, so it's questionable whether we want to support it even in
the long term... for now, it's just a dummy that calls strcmp.

also modify wcsncpy to use the same loop logic

this could actually cause rare crashes in the case where a short
string is located at the end of a page and the following page is not
readable, and in fact this was seen in gcc compiling certain files.

search for bytes with high bit set was giving (potentially dangerous)
wrong results. i've tested, cleaned up, and hopefully sped up this
function now.

sadly the C language does not specify any such implicit conversion, so
this is not a matter of just fixing warnings (as gcc treats it) but
actual errors. i would like to revisit a number of these changes and
possibly revise the types used to reduce the number of casts required.

this only made the function unnecessarily slow on systems with
unaligned access, but would of course crash on systems that can't do
unaligned accesses (none of which have ports yet).