[webkit-dev] type of JSChar
darin at apple.com
Fri Jul 27 09:56:40 PDT 2007
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
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
The same issue exists on Mac OS X, but on that platform the types for
characters, Unichar and unichar, are unsigned short.
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
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.
More information about the webkit-dev