nmh-workers
[Top] [All Lists]

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

2013-01-03 23:50:22
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>