[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] fix locale string reading

From: Peter Brett
Subject: Re: [PATCH] fix locale string reading
Date: Wed, 09 Nov 2011 10:20:00 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

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

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 Brett <address@hidden>
Remote Sensing Research Group
Surrey Space Centre

reply via email to

[Prev in Thread] Current Thread [Next in Thread]