Daiki Ueno wrote: > KO Myung-Hun <kom...@gmail.com> 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
