Re: -fshort-wchar option, wchar_t and Native<->Unicode conversion

Darin Fisher wrote:

darin,

Thanks for the comment.

 >> In
 >> 
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsNativeCharsetUtils.cpp#623, 


> yeah, i'm not convinced we are doing the right thing either.  what we do 
> is cast each PRUnichar (in a *PRUnichar) to a wchar_t and then pass that 
> to wcrtomb (one PRUnichar at a time).  assuming that wcrtomb does indeed 
> expect a code point from ISO 10646/Unicode, i'm not sure how it would 
> handle an element of *PRUnichar.  is it valid to zero-pad expand UTF-16 
> to form UCS-4?  probably not, in which case our linux code is certainly 
> busted.

   Yes, it's busted although the symptom won't manifest itself in the 
near future unless a brave soul makes a filename with non-BMP characters 
:-) What shall we do? Is there really a big perf. penalty if we use 
iconv  instead of wcrtomb and mbrtowc on Linux as commented in the 
source? If not, we can just  make Linux build use iconv, instead.
Alternatively, we can do in-place utf-16 <-> ucs4 conversion if wchar_t 
is UCS4, but wouldn't that cancel out whatever perf. gain we're getting 
from not using iconv(3)?


Jungshik