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

Re: [Public WebGL] TypedArray constructors and zero length

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 .

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: