[webkit-dev] type of JSChar

[Darin Adler]

On Jul 27, 2007, at 7:45 AM, Darin Adler wrote:

> On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
>
>> On 7/27/07 1:51 PM, "Simon Hausmann" <hausmann at kde.org> wrote:
>>
>>> Does anybody know/remember why JSChar is defined to wchar_t on  
>>> Windows and if
>>> it is still needed?
>>
>> I think this was/is needed to match ICU's definition of UChar  
>> ("Define UChar to be wchar_t if that is 16 bits wide; always  
>> assumed to be unsigned. If wchar_t is not 16 bits wide, then  
>> define UChar to be uint16_t. This makes the definition of UChar  
>> platform-dependent but allows direct string type compatibility  
>> with platforms with 16-bit wchar_t types.")
>
> That's correct. And for the same reasons we should follow the same  
> pattern for UChar, even when ICU is not involved.
>
> I think that UnicodeQt4.h is the file that should be changed, not  
> JSStringRef.h.

I should be more specific about the reasons I have for preferring this.

It's a good feature for both JSChar and UChar that on the Windows  
platform, the 16-bit unsigned integer type they use is wchar_t,  
rather than unsigned short. That's because there are all sorts of  
Windows Unicode APIs that take wchar_t, and it's great to have the  
type match.

The same issue exists on Mac OS X, but on that platform the types for  
characters, Unichar and unichar, are unsigned short.

Anyway, for the JavaScript API, it's great to have the character  
typedef match the platform typedef, as long as the platform typedef  
is a 16-bit unsigned integer. I'd like us to preserve that feature  
even when building for Qt. That increases the chance that client code  
using the JavaScript API can be independent of the particular  
underlying JavaScriptCore implementation.

Also, since JSStringRef.h is an API header, it's not good to have it  
depend on an project-internal define, so that's another reason to  
remove the recent change to JSStringRef.h.

     -- Darin