Re: [PATCH] fix locale string reading

[Peter Brett]

Nala Ginrut <address@hidden> writes:

> But Guile will break in (command-line) proc, because Chinese string as
> command arguments can not get valid result from
>  "u32_conv_from_encoding" called by "scm_from_stringn", and raised an
> error. 

Probably what should happen is that Guile's command-line parsing code
should use the environment-provided locale by taking the following
steps:

1) Save current locale.
2) Set locale from environment.
3) Call scm_*_locale_string() functions.
4) Restore original locale.

However, note that this still may cause decoding errors, because there's
no guarantee that argv is in the same encoding as the environment
specifies, or indeed in any valid encoding at all.  So consider *also*
adding e.g. a (command-line-bv) function to return the command line
without attempting to decode it.

> So we don't have any chance to convert it or change locale from
> environment in the users' code because Guile has already crashed by
> "decoding-error".

Hang on -- are you saying that if you run Guile with badly-encoded argv
then it will die before running any user code?  That would obviously be a bug.

> Now I have two questons:
> 1. Maybe we raised this "decoding-error" too early. Can we let
> "scm_from_locale_stringn" just return the string which
> wasn't recognized as a bytevector? Then we may convert it as wish. But
> it's confused for "scm_from_locale_stringn" returning a bytevector;

No, you can't do that, because scm_*_locale_string is supposed to either
return a string or raise "decoding-error".

> 2. Why not let "scm_from_locale_stringn" return string according to
> the locale from current environment as my patch?

Because it breaks existing code that relies on current behaviour *and*
doesn't actually fix the problem.

                      Peter

-- 
Peter Brett <address@hidden>
Remote Sensing Research Group
Surrey Space Centre