gnupg-1.0.2 patch: LC_CTYPE needs to be imported

[Daniel Resare]

On Wed, Aug 16, 2000 at 03:25:04PM +0200, Werner Koch wrote:
> On Tue, 15 Aug 2000, Daniel Resare wrote:
> 
> > was tranlated into US-ASCII by glibc. To correct this problem the
> > LC_CTYPE locale needs to be something else than "C". The included
> 
> >From the man page:
> 
>        The  setlocale() function is used to set or query the pro­
>        gram's current locale.  If locale is "C" or  "POSIX",  the
>        current locale is set to the portable locale.
> 
>        If  locale  is "", the locale is set to the default locale
>        which is selected from the environment variable LANG.
> 
>        On startup of the main program, the portable "C" locale is
>        selected as default.
> 
> By using "" we use isxxxxx() functions which handle 8 bit characters and
> that is something for which the program is not designed.  The problem must
> be somewhere else.  Using setlocale() for LC_TIME and _MESSAGES is what we
> actually want (if we have those and are not forced to use LC_ALL).
> 

Ok, i'll take this up with the glibc guys. Let me just se if i get this
correctly:

The LC_CTYPE locale category traditionally only had effect on
the functions in ctype.h (isalpha() and so on) not on which
characters that can be printed on the screen. Gnupg relies on
isalpha() and firends to use the US-ASCII charset when dtermining
what is a character and what is not. Therefore the LC_CTYPE
needs to be set to C (the value that it as a coincidence has
when untouched). With the advent of the new glibc the LC_TYPE
also affects what characters that should be displayed in a
console. Therefore internationalized messages from gnupg gets
munged into US-ASCII by glibc. Possible solutions to the problem:

1) Ask the glibc maintainers kindly not to let the LC_CTYPE
   affect console output. That behaviour is IMHO unobvious and
   should be considered an extention so large that a new LC_
   category could be invented for the purpose.
  
   * interesting question: how does this work on other systems?

2) wrap all calls to the ctype.h functions (isalpha() and friends
   in setlocale(LC_CTYPE, "C")) (some grep'ing shows 56 occurances)

3) review all uses of the ctype.h functions and perhaps use the
   isascii() function instead where appliciable (according to
   the manpage isascii() is a BSD and SVID extension and should
   be quite widely available)

4) write platform indipendent replacements of the used ctype.h
   functions that check against the US-ASCII charset. (Shouldn't
   be difficult)

If needed, I could volunteer for the work. (If my wife doesn't
kill me *smile*)

cheers
/daniel


-- 
nuclear cia fbi spy password code president bomb
8D97 F297 CA0D 8751 D8EB  12B6 6EA6 727F 9B8D EC2A