Thanks for your explanation.
To all appearances X_LOCALE was purposed for systems where libc has not
a locale support. If X_LOCALE is defined Xlib replaces setlocale with own
Xsetlocale which just keeps a locale name (and returns it being asked) and
doesn't touch libc's setlocale.
But in such case Xlib should not use any locale-depended functions (such as
mblen) from libc but replace them too with own corresponded functions.
Xlib has such substitutes (e.g _Xmblen for mblen) but it seems they don't
depend on X_LOCALE condition. The fact that in your tests mblen changes its
behaviour when you call libc's setlocale, shows that namely libc's mblen is
used there.
Yes.
I think the right solution is to add the right condition (replace mblen with
_Xmblen if X_LOCALE is defined) somewhere. Such substitution already is in
Xlib.h but there it depends on another conditions.
OK. I experimentally replace mblen with _Xmblen in imCallbk.c, but this doesn't work. I don't know why but _Xmblen(char_tmp, strlen(char_tmp) always returns strlen(char_tmp) in my test. This is not the expected value since libc's mblen returns number of bytes in *next* multibyte character. Is _Xmblen also broken??
On the other hand if in your system selocale works and makes mblen working
correctly, why your Xlib is built with X_LOCALE ?
Mac OS X 10.2's libc is partially broken in terms of locale support. mblen, wctomb, and mbtowc seems to work fine with LANG=ja_JP.eucJP, but mbstowcs and wcstombs doesn't work properly. Also LC_TIME and LC_COLLATE are not implemented. So, I think Mac OS X still uses X_LOCALE defined XFree86.
Regards, -- Etsushi Kato [EMAIL PROTECTED]
_______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
