Re: [PATCH 02/14] Fix character encoding aliases for OS/2

[KO Myung-Hun]

Daiki Ueno wrote:
> KO Myung-Hun <address@hidden> writes:
> 
>> Thanks. ^^ And fixed typo, cp1361 to cp1381.
> 
> Oops, thanks for fixing.
> 
>>> By the way, it's tempting to call DosQueryCp if a charset is omitted
>>> from the locale name, to avoid maintaining the default mapping
>>> ourselves.  I'd rather not do that for now, but is it feasible?
>>
>> This was my first idea. But Bruno rejected. See
>>
>> http://lists.gnu.org/archive/html/bug-gnu-libiconv/2011-03/msg00000.html
> 
> Thanks for the link.  If I understand correctly, the main point seems
> that the patch affects the codeset of the POSIX locale ("C" or "POSIX").
> 
> For other locale values, POSIX says:
> 
>   If the locale value has the form:
> 
>   language[_territory][.codeset]
> 
>   it refers to an implementation-provided locale, where settings of
>   language, territory, and codeset are implementation-defined.
> 
> So, I don't see any problem using system's codepage as a default codeset
> of a language_territory locale (though it might conflict with the
> libiconv design).  FWIW, kLIBC's nl_langinfo/setlocale implementation
> does this:
> 
> - if codeset is specified as part of the locale name, use it
> - if the locale name is "C" or "POSIX", use "US-ASCII"
> - otherwise, fallback to DosQueryCp
> 
> I'm attaching two patches: the first one is an update of the patch we
> are currently working on (I added mappings from the "unusable" codepages
> to their equivalents), and the second one is an alternative
> implementation following the kLIBC implementation.

I prefer second one. It was my first idea and more simple. ^^

Thanks a lot for your works.

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

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