[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] TypedArray constructors and zero length

I've noticed it's already been fixed in WebKit trunk.
I think behavior clarifications as in the bug's point 1 to 3 should be
included in the TypedArrays spec to ensure consistent behavior and
proper test coverage.


On Thu, Jun 17, 2010 at 10:33, Kenneth Russell <kbr@google.com> wrote:
> On Thu, Jun 10, 2010 at 1:15 PM, Cedric Vivier <cedricv@neonux.com> wrote:
>> On Fri, Jun 11, 2010 at 01:49, Kenneth Russell <kbr@google.com> wrote:
>>> On Thu, Jun 10, 2010 at 2:12 AM, Cedric Vivier <cedricv@neonux.com> wrote:
>>>> FWIW I wrote some tests on this today, Mozilla has the sane behavior
>>>> of throwing an exception ("invalid array size") when length is
>>>> negative while WebKit swaps like crazy attempting to allocate
>>>> memory... and in the end returns "undefined".
>>> After looking back at the JavaScript bindings in WebKit, the intended
>>> behavior is that this should throw an INDEX_SIZE_ERR exception. See
>>> http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSArrayBufferConstructor.cpp
>>> , line 61, and http://trac.webkit.org/browser/trunk/WebCore/bindings/v8/custom/V8ArrayBufferCustom.cpp
>>> , line 77. I'm not sure why this isn't happening. Feel free to file a
>>> bug on http://bugs.webkit.org/ .
>> Interesting, I guess in V8's case it setting DOM exception is not
>> enough as an exception object must be passed/returned to the runtime.
>> Looks like the behavior is inconsistent between the 2 WebKit bindings
>> even for some corner cases (NaN/+inf/-inf gives 0 on JSCore - as
>> WebIDL specifies - but throws on the V8 binding).
>> Mozilla does indeed treat the input as an int32 internally and
>> specifically check if the value is negative (which also means "too
>> big" >2^31 depending how you look at it sure, but in the end it just
>> works as intended by WebIDL's unsigned long... a signed value passed
>> as parameter will not work and won't have side-effects [like
>> attempting to allocate possibly huge chunk of memory]) :
>> http://mxr.mozilla.org/mozilla-central/source/js/src/jstypedarray.cpp#137
>> I think reproducing Mozilla's behavior in both WebKit bindings would
>> make a lot of sense, for instance with this patch for V8's binding :
>> http://neonux.com/webgl/v8-binding-arraybuffer.patch
> Thanks for the initial patch. Generally agree about clarifying the
> error behavior. Some different and additional error checks were
> needed. FYI, this is being worked on under
> https://bugs.webkit.org/show_bug.cgi?id=40755 .
> -Ken
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: