Hello rigel, On Monday, October 16, 2000, rigel wrote: >> 1. Don't use environment variables to determine locale settings. In >> particular, do NOT use the value returned by setlocale(3) to >> determine the current locale's encoding! Instead, use >> nl_langinfo(3) for this purpose.
r> Good point. However I don't think it's glibc 2.2 issue. Actually if you stick r> with glibc only this is not a very big issue, because you always know how r> the locales are named (well, kind of). It's a serius issue when you want your r> program also runs on other unix systems with their native C library. That's r> when the naming conventions becomes wild. So if portability is a concern, r> nl_langinfo should be used no matter what C library you work with. setlocale and nl_langinfo should be used conjunctly to construct a locale under glibc 2.2.x. r> Just a small thing. A new LC_CTYPE class "hanzi" was added in glibc 2.2 r> locale (both zh_CN and zh_TW have it, zh_HK doesn't though). It currently r> contains all the unicode unihan characters. I don't know how useful this r> is (your comments on this are welcomed). In case some one is interested in r> this, here is a sample implementation of "iswhanzi(wchar_t wc)" This would make parsing hanzi string easier. Also handy for line breaking detection, I think. It is just that it is not portable :(. -- Best regards, hashao mailto:[EMAIL PROTECTED] -- | This message was re-posted from [email protected] | and converted from gb2312 to big5 by an automatic gateway.
