Bug 77317 – JSC::JSValue doesn't support UInt32 properly.

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore JavaScript

[Kihong Kwon]

JSC::JSValue doesn't support UInt32 properly.

UInt32 follows an unsigned long defined by (http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long), which present a number between [0, 4294967295]

Since UInt32 has the same range as Int32 (~2147483647) in JSValue, we cannot support an unsinged long parameter for the Javascript APIs with JSC.

[Gavin Barraclough]

JSC support the ECMA-262 defined toUint32 conversion correctly (see ES5.1 section 9.6).  If WebIDL wants a different conversion, this is probably best supported in a wrapper function in WebCore/bindings, rather than in JSC.

This can be implemented in terms of JSValue::toNumber (as the WebIDL spec calls for), optionally optimizing access to integers using JSValue::isInt32 & JSValue::asInt32.

This bug should probably be retitled – JSC's toUint32 matches that of the appropriate spec.

[Kihong Kwon]

(In reply to comment #1)
> JSC support the ECMA-262 defined toUint32 conversion correctly (see ES5.1 section 9.6).  If WebIDL wants a different conversion, this is probably best supported in a wrapper function in WebCore/bindings, rather than in JSC.
> 
> This can be implemented in terms of JSValue::toNumber (as the WebIDL spec calls for), optionally optimizing access to integers using JSValue::isInt32 & JSValue::asInt32.
> 
> This bug should probably be retitled – JSC's toUint32 matches that of the appropriate spec.

I have this codes in custom JS file.
---------------------------------------------
JSValue value = exec.argument(0);
if (value.isUInt32())
...
---------------------------------------------
When I input greater than equal 2^31(like 4294967295) to an argument, isUInt32() returns false. I think it have to return true. Am I wrong?

[Gavin Barraclough]

(In reply to comment #2)
> When I input greater than equal 2^31(like 4294967295) to an argument, isUInt32() returns false. I think it have to return true. Am I wrong?

Ah, fair point, the isUint32() and asUint32() methods are currently rather poorly named – the names got shortened a while back for brevity, but they should probably be clearer.  These used to be called isFastUInt32() and asFastUInt32(), which was a little better.  The intention of these methods is not to definitively state whether the value is a number in the UInt32 range, rather, whether the value is in the UInt32 range and also is currently being represented as an integer (for example, the value 1 may be represented as the integer 1, or the double 1.0 – by design this method will return false if the value is stored at 1.0).  These methods exist only to implement optimized code paths – they may produce false negative results (the intention being that this would just result in slower handling).

We certainly could provide a method that would definitively return true for all integers in the range 0..0xFFFFFFFF regardless of whether they are current represented as an integer or double – but if we did, how would you use it? – Web IDL requires a ToNumber conversion to be performed, so a UInt32 result may be produced from a value that is non-numeric.  Is there a use for a more expensive, accurate isUInt32 here?

JSValue provides the ToNumber method required by step 1 of the Web IDL conversion to unsigned long:
    double toNumber(ExecState*) const;
And provides the ECMA-262 ToUInt32 conversion required by step 4, both as a method and as a convenient fee function:
    inline uint32_t toUInt32(double number)

This should be all you need to implement the Web IDL specified conversion, but you may also wish to use isUInt32/asUInt32 to provide a fast path.

[Kihong Kwon]

I see - I can handle what's necessary in my patch with toNumber() and toUInt32(). As you have also pointed out, isUInt32() and asUInt32() are rather poorly named, and thus, IMO, their names should be changed properly.

Thanks for your comment!