[webkit-dev] type of JSChar

[Lars Knoll]

On Friday 27 July 2007 18:56:40 Darin Adler wrote:
> 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.

I do understand this for your Windows port. In Qt we try to have the same 
types across all platforms. This is also true for our QChar abstraction that 
is built on top of an unsigned short. So for us typedef'ing this to wchar_t 
is as wrong as unsigned short would be for your windows port.

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

For the Qt port, the 'platform' typedef is an unsigned short. So one could say 
that the #ifdef for __BULDING_QT does about the same thing as the #ifdef 
(WIN32) for your Windows port.

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

Well, it's not an API header for us. Still it's used internally in WebKit, so 
we need to do something with the typedef. Different ports do sometimes have 
slightly different goals.

Cheers,
Lars