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

[KO Myung-Hun]

Hi/2.

Bruno Haible wrote:
> Hi,
> 
> KO Myung-Hun wrote:
>>>> 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.
> 
> ... and if the platform has no working locales. Yes. But your patch modified
> the behaviour of locale_charset() when environment variables are set.
> 
>>> - 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.
> 
> The codepage is to be used when no environments are set (and setlocale is
> non-functional or has not been called). charset.alias is to be used when
> the user has specified a locale through environment variables.
> 
>> There is no need to refuse to use another choice obstinately.
> 
> Your patch 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 makes no sense,
> because charset.alias is designed to handle this case.
> 

Ok, I realized what the problem is. I considered LANG format only. I
attach the fixed patch.

>> Even more, WIN32_NATIVE implementation does not care about the
>> environmental variables at all.
> 
> You're right, that may be a bug. gnulib now has a setlocale() for native
> Win32 that looks at the environment variables and does the necessary
> conversions between Unix locale names and Win32 locale names. It is well
> possible that locale_charset() and nl_langinfo(CODESET) should use the
> charset that matches the locale set via setlocale().
> 
> But this applies only to platforms that have a full, working set of locales.
> I think OS/2 (emx+gcc) is not in this camp.

OS/2 kLIBC (successor of emx) supports locales well.

-- 
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

0001-If-codeset-is-not-set-by-the-user-use-a-codepage-for.patch
Description: Text document