Re: [Nmh-workers] bug in decode_rfc2047()

[Ken Hornstein]

>It's unfortunate that there isn't a more general version of
>mbtowc() that takes a codeset as a parameter.  Then we could use
>use it the way that fmt_scan() does to find out how long the next
>character is.  I don't think it's worth changing the locale just
>to call mbtowc().

There is a mbtowc_l() on some systems (at least my MacOS X) box.  I guess
that's part of xlocale.  But yeah, I don't think changing the locale is
worth it either if that doesn't exist.  It also doesn't seem like you can
use that as a general purpose character conversion routine, unfortunately.

>I (finally) setup my xterms to handle UTF-8.  I noticed that
>scan lines get shortened when there are multibyte characters.
>fmt_scan()'s cpstripped() doesn't count them.  It doesn't look
>like it'd be hard to fix using the info from mbtowc() that it
>already has, but I think an additional parameter will be needed
>to prevent overflow of the dest buffer.  And cptrimmed() could
>use the same fix.

Right, remember when we talked before about adding the support for
escape sequences, which required decoupling the desired column width
from the number of output bytes?  That was my real motiviation :-)
But I see you already committed a fix!

--Ken