gnupg-1.0.2 patch: LC_CTYPE needs to be imported

[Edmund GRIMLEY EVANS]

Werner Koch <wk@gnupg.org>:

> > Where UTF-8 is specified for data that is transmitted between
> > machines, on a modern system you should be able to convert between
> > UTF-8 and the locale charset using iconv, and find out what the locale
> > charset is using nl_langinfo(CODESET).
> 
> Quite some time ago, Thomas Roesler told me that there is no portable
> way to query the locale charset.  It seems that this has changed and
> in every case we can do an autoconf check for nl_langinfo and check
> whether the iconv implemenation regarding UTF-8 is "secure", meaning
> not to allow overlong UTF-8 encodings to give a different encoding for
> the standard ASCII characters like LF or BS.

Is that check definitely necessary, or you just being extra careful?

> BTW, do you know what happens in glibc's iconv when an invalid
> sequence etc. is encountered?  I assume you get one of the error codes
> back and then you have to output ? or C-qouted characters.

An invalid sequence gives EILSEQ. According to the spec, a valid input
sequence should always be converted by iconv, even if the conversion
is non-reversible. In practive, every implementaton of iconv sometimes
returns EILSEQ in this case, too. The implementation in glibc-2.1
never converts non-reversibly and also gives a different return value
from the spec. If you're lucky, you can ignore these implementation
annoyances and always do the same thing when you get EILSEQ: output
the original octet as ? or quoted and advance the input pointer.

I discovered the following with Mutt, which might or might not be
relevant for you:

dnl (2) In glibc-2.1.2 and earlier there is a bug that messes up ob and
dnl     obl when args 2 and 3 are 0 (fixed in glibc-2.1.3).

Edmund