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