[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 04:51, Kenneth Russell <email@example.com> wrote:
> On Wed, Jun 9, 2010 at 12:27 PM, Cedric Vivier <firstname.lastname@example.org> wrote:
>> Should we replace type of length with "long" instead so that we can
>> generate an error in case a negative value is passed ?
> No, we should definitely not do this. We had a host of issues with the
> TypedArray implementation in WebKit due to the use of signed values
> where conceptually negative values are invalid.
Changing argument type is probably not be the best solution indeed,
conceptually unsigned makes sense, however there is still issues at a
level higher than implementation imho because of WebIDL's lack of
potential stricter conversion rules (ie. no OverflowException or
similar concept when a negative value is passed to a unsigned argument
which conceptually require a positive value), hence the second part of
the question :
> Or perhaps this needs modification in WebIDL spec and/or addition of a
> stricter conversion rule parameter attribute (ie. possibly raising
> TYPE_ERR or OverflowException) ?
> 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
Rather than directly failing at creation time (with an exception),
which is easy to debug, it will fail at an undefined later point with
another exception, possibly from a different object as a result of a
sequence of events - or worse, executing with unexpected behavior...
this goes against fail-fast principle and looks like a potential
debugging hell for WebGL developers imho.
will immediately stop with an exception, like almost every language/framework.
How is having different argument error handling a benefit here ?
IMO whether or not unsigned-to-integer overflow is specified by WebIDL
someday, we should stick to the fail-fast principle and raise an
exception when a TypedArray cannot be allocated for whatever reason
(ie. not enough memory or not allowed to perform large allocation,
possibly because passed length was bogus/negative).
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: