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

Yeah, I wrote that comment about mbrtowc/wcrtomb being faster, but I 
don't have my testcases anymore.  I'm not sure how much faster it was... 
it might be good to construct some new tests to verify that statement ;-)

Darin


Jungshik Shin wrote:

> 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
>