Re: [PATCH] fix locale string reading

[Peter Brett]

Nala Ginrut <address@hidden> writes:

> This couldn't be the final solution.
> Even we add a (command-line-bv), it may cause encoding-error. Because
> (command-line) would read argv too , and raise the error.
> Unless we use (command-line-bv) and delete (command-line).

(command-line-bv) should never cause an "encoding-error", because it
should never try to decode the command line.

Users of (command-line) should catch a potential "encoding-error" and
handle it appropriately.

> I think so. I mentioned it in the first mail of this thread.
> The badly-encoded argv can not get valid result but NULL
> from  "u32_conv_from_encoding". So scm_from_locale_stringn will raise
> encording-error directly and show the argv as bytevector.
> But even none-badly-encoded argv can not get valid result either. I checked 
> out
> the code, current_charset() can not return the correct current locale. I must
> run setlocale(LC_ALL,"") to query locale from environment first. 
> But I think what you mean is *not query locale from envrionment*. 
>
> If this is not a bug. And locale string can not get result from environment
> locale. The solution maybe get rid of (command-line), use (command-line-bv),
> it's the easiest way. But I don't think it's the best way.

Well, you still need to provide (command-line) and (program-arguments)
functions compatible with existing code.  I think the root of the
problem is that Guile calls scm_set_program_arguments() [feature.c:72]
early in initialisation, and this can fail messily.

I still think your proposed "solution" causes WAY more problems than it
claims to solve, though.  What do Andy & Ludovic think?

                         Peter

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