Re: UTF-8 regression in guile 1.9.5

[Mike Gran <spk121@yahoo.com>]

> From: Andy Wingo <wingo@pobox.com>


> Hi,
> 
> Reviving an old thread...
> 

> > I think I prefer that the coder take the responsibility of calling
> > setlocale, but, I only think that because it is how C works.  I'm used
> > to that convention.
> 
> I would still prefer ponies and magic, but I realized: if we do a
> setlocale(LC_ALL, "") at the beginning, might that not change e.g. the
> floating point format, or some other locale-related variable, which
> would make Guile modules unreadable, or otherwise semantically different
> or invalid?
> 
> I'm asking because I ran into this bug now:
> 
>     scheme@(guile-user)> ,pr (resolve-module '(gnome gtk))
>     Throw to key `wrong-type-arg' with args `("procedure-name" "Wrong type 
> argument in position ~A: ~S" (1 #) 
> (#))'.
>     Entering the debugger. Type `bt' for a backtrace or `c' to continue.
>     0 debug> bt
>     In current input:
>     : 13 ERROR: cannot convert to output locale "NONE": 
> ""dynamic-wind""
> 
> So I guess we need a special case for NONE there, or something. I really
> don't understand i18n/l10n.

A LOCALE=NONE is the same as setting locale to any undefined value,e.g.
LOCALE=martian_mars.  There isn't a locale called 'none', so the system 
can provide no clues on how I/O, date format, etc, should be done.

All programs are supposed to start with locale="C", so I guess the
NONE locale is being set explicitly at some point.  On my box, I can't
(setlocale LC_ALL "NONE") since I don't have a NONE locale.

So, the fact that locale=NONE seems like a bug to me.

For Guile string conversion, if locale=NONE has some non-buggy meaning, 
I'd probably suggest making NONE the same as UTF-8.  We can do whatever
we want, since the result of the operation of conversion into NONE
is undefined.

But as far as the greater question of the side effects of setting locale
early on startup...  The parsing of any source code files after locale 
is set will be done in that context.  I don't think it would do anything
unexpected. The reader and the port routines tend to do their own parsing,
and don't tend to rely on libc locale-specific routines.  Even so, it 
would take some auditing to prove that there would be no effect.

If you were to set the locale in Guile, you would need to add
a condition to catch if the current LANG envvar isn't set to a valid
locale so you can fall back to the "C" locale.

-Mike Gran