Re: [bug-gnu-libiconv] [PATCH] OS/2 patches for libiconv

[KO Myung-Hun]

Hi/2.

Bruno Haible wrote:
> Hi,
> 
> KO Myung-Hun wrote in
> <http://lists.gnu.org/archive/html/bug-gnu-libiconv/2011-03/msg00000.html>:
>> I attach OS/2 patches for libiconv.
> 
> Thank you for the patches.
> 
>> 0001-Add-EXEEXT-to-iconv_no_i18n.patch
> 
> This one is fine. It matches the recommendation by Ralf Wildenhues in
> <http://lists.gnu.org/archive/html/bug-libtool/2009-04/msg00013.html>. 
> Applied.
> 

Thanks.

>> 0002-If-codeset-is-not-set-by-the-user-use-a-codepage-for.patch
> 
> This one has the effect that when the user has set the environment variable
> LC_ALL or LC_CTYPE or LANG to a value that contains no dot, then the program
> will use the encoding from the codepage in the OS.
> 
> This is not good, because that's not how POSIX programs are supposed to
> behave
> (see 
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html>):
> 
> - If LC_ALL, LC_CTYPE, or LANG are set to a non-empty value, this value holds.
>   What localcharset.c does additionally is that it maps locale names to
>   encodings. But in any case it is important that in the "C" locale the
>   results don't depend on operating system settings, because users on 
> different
>   machines should get the same results.
> 

I could find that C or POSIX locale should be assumed if charset is not
specified by those environmental variables.

Is this your assumption ? Or where can I find it ?

> - If LC_ALL, LC_CTYPE, LANG are not set, _then_ the program is free to use
>   the settings from the operating system (see POSIX, above):
>     "All implementations shall define a locale as the default locale, to
>      be invoked when no environment variables are set, or set to the empty
>      string. This default locale can be the POSIX locale or any other
>      implementation-defined locale. Some implementations may provide
>      facilities for local installation administrators to set the default
>      locale, customizing it for each location."
> 
> So, if you found that localcharset did not return the encoding you expected,
> then either
>   - unset some environment variables, or
>   - add a mapping from locale name to encoding in the file charset.alias.

Codepage can be used as well as charset.alias on OS/2.

There is no need to refuse to use another choice obstinately.

Even more, WIN32_NATIVE implementation does not care about the
environmental variables at all.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.11
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr