Hi Christoph,
On Friday, March 9, 2007 at 17:50:24 +0100, Christoph Berg wrote:
> does "fixing" this also affect #249626/402035?
The hooks fixing #402027 will also prevent most the symptoms
described in #402035 (only the unconvertable "?h" stays). But the
underlying problem is still there, and generates symptoms in other
circumstances. They do not affect #249626.
> From reading the reports, there's probably not much we could do short
> of reassigning the bugs to iconv. (I'm pondering tagging these
> wontfix.)
Let's see: #249626 context is ISO-2022-JP valid input not
convertable. The symptoms are located where the bytes can *only* come in
pairs (after an ESC $ B sequence). Resyncing after an error should be
easy. The iconv command gives good results on the test cases. But Mutt
fails. I think it's clearly a Mutt bug.
#402035 context is a mix of valid input not convertable, and invalid
input in the same string. Symptoms are located where the bytes can come
single (Ascii) or in pairs (CJK). Thus it's more difficult to resync
after an error. Mutt and the iconv command both give bad results. Those
results are not identical, which could be an effect of #249626 (weak
guess). Anyway I think it's a problem of the iconv lib, perhaps a bug.
I'd suggest to unmerge #402035 and reassign it to iconv people (where
exactly: glibc?). Do you agree?
Further about #249626, I fear it could be the "economic" direct way
Mutt calls the iconv() in lib. Mutt should perhaps do a two stage
conversion (fromcode to Unicode, then Unicode to tocode), dealing itself
with all intermediate errors. This approach would give some infos on
what is a character (vs a byte), and permit to skip a whole invalid (or
unconvertable) character. This approach would also cost twice the
horsepower, twice the memory, and twice the complexity... Hopefully
there is a simpler way to fix it.
However I'm strongly against a wontfix tag, given the big annoyance
this bug provides to multibyte locales (out of UTF-8 of course). It can
change a perfectly valid text to whole nonsense.
Bye! Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The [EMAIL PROTECTED] project at <URL:http://folding.stanford.edu/>.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
