[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 2:12 AM, Cedric Vivier <firstname.lastname@example.org> wrote:
> On Thu, Jun 10, 2010 at 06:44, Cedric Vivier <email@example.com> wrote:
>>> While -1 will convert
>>> to a large number, implementations are expected to attempt the
>>> allocation, fail, and return a buffer with zero length.
>> Are you implying TypedArray construction can never fail then ?
>> IF returning a zero-length array is the behavior only when "a large
>> number" is passed, how implementations should differentiate "a large
>> number" which couldn't be allocated from "out of memory (within the
> 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".
behavior is that this should throw an INDEX_SIZE_ERR exception. See
, 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/ .
> If we do not simply go for changing length type in constructors (only
> ) to 'long', I guess we should somehow specify stricter conversion
> rules in WebIDL so that passing an out of range value to a unsigned
> parameter throws as expected (and therefore provide consistent defined
>  : other attributes are not an issue since they are "readonly" or
> have specified behavior wrt values are out of range (e.g slice,...),
> the issue is only present for constructor as it is an "in" value.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: