-fshort-wchar option, wchar_t and Native<->Unicode conversion
Jungshik Shin <[email protected]> Fri, 23 May 2003 08:40:12 +0900
| Newsgroups | gmane.comp.mozilla.internationalization,gmane.comp.mozilla.devel.unix,gmane.comp.mozilla.devel.xpcom |
|---|---|
| Organization | Another Netscape Collabra Server User |
| Message-ID | <[email protected]> |
In http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsNativeCharsetUtils.cpp#623, it's assumed that *wchar_t is the same as *PRUnichar when gWCharIsUnicode is true. I'm wondering if it's always the case. At the momemnt, Linux build is made with '-fshort-wchar' option to gcc. With that option, wchar_t is short(2byte) and *wchar_t is the same as *PRUnichar as far as non-BMP char is concerned. Even in that case, I'm not sure *wchar_t is identical to *PRUnichar. It's to be note that *PRUnichar is NOT a string of UCS2 BUT a 'UTF-16 string'. I'm not sure what gcc does when '-fshort-wchar' is turned on. That is, I'm wondering whether '-fshort-wchar' makes *wchar_t 'UTF-16 string' as opposed to 'UCS2 string'. If not, UnicodeToNative and NativeToUnicode are broken for non-BMP characters. Even more serious is that *wchar_t is a string of PRUInt32's on Linux(glibc,gcc) if '-fshort_wchar' is not used. How about other compilers on other platforms? '-fshort_wchar' is only available in gcc, isn't it? [1] How about the interaction between '-fshort-wchar' and '__STDC_ISO_10646__' (ISO C 99)? If the latter is defined, wchar_t is supposed to be UCS4. Does '-fshort-wchar' override it? If so, do we plan to use '-fshort-wchar' permanently? A possible work-around for this problem is to use 'iconv' in place of mb rtowc and wcrtomb. Jungshik [1]I'm aware that on some platforms, wchar_t is locale-dependent and it's not even ISO 10646/Unicode, but let's just leave it aside for this discussion.