That would help. But I think that the whole business should
be reviewed and possibly redesigned. As in, provide an sbr
function to say whether or not two charset names match.
Callers that just need that would no longer have to be
concerned with memory management.
I just realized something ... we're using norm_charmap() wrong.
The purpose of norm_charmap() is to convert a _locale_ character set
(what is returned by nl_langinfo(CODESET)) into a standard MIME
character set. AFACT, norm_charmap() should almost never be used by
nmh applications; they should be using get_charset() if they need
the local character set. If it's something in email, we can use it
directly and it should not be run through norm_charmap().
I don't follow. What if the email says that it's something
that norm_charmap() would convert to US-ASCII or one of the
others that it modifies. How do we know if that matches
the user's locale character set?
And with mhfixmsg, the user's locale doesn't enter in at
all. The user can translate the message from whatever
it is to whatever the user wants (assuming that iconv
supports the translation). mhfixmsg uses norm_charmap()
when deciding whether that translation isn't necessary.
I'd be OK with removing the norm_charmap() here, on the
assumption that users (and emails) will say "US-ASCII"
and not one of its aliases.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers