gnupg-1.0.2 patch: LC_CTYPE needs to be imported

Edmund GRIMLEY EVANS edmundo@rano.org
Thu, 17 Aug 2000 13:52:55 +0100


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