[Public WebGL] WebGL IDL includes overloads that are not allowed in WebIDL

Kenneth Russell [email protected]
Mon Apr 2 18:07:23 PDT 2012

On Mon, Apr 2, 2012 at 7:19 AM, Boris Zbarsky <[email protected]> wrote:
> Specifically, it has:
>    void bufferSubData(unsigned long target, long long offset,
> ArrayBufferView? data);
>    void bufferSubData(unsigned long target, long long offset, ArrayBuffer?
> data);
> This is not allowed because if null is passed for the third argument the
> overload resolution algorithm would not be able to decide which of the two
> overloads to invoke.

Thanks for pointing this out. For the moment I've resolved this by
making the ArrayBufferView? argument in the first overload
non-nullable. I also changed the bufferData overload taking
ArrayBuffer to make that argument nullable to resolve that resolution

Are you using a tool to discover these issues in WebGL's IDL? If so,
could you please send a pointer to the mailing list? I don't think any
of the web browsers' build process accept vanilla Web IDL, and it's a
big problem that the IDL has never been machine validated.

> I'm not quite sure why this is using a nullable type at all, honestly. For
> one thing, the spec doesn't quite define behavior when null is passed.
>  OpenGL ES section 2.9 has, for this function, the signature:
>  void BufferSubData( enum target, intptr offset, sizeiptr size,
>                      const void* data );
> and doesn't really define what happens for null |data| (contrast with
> BufferData earlier in that section, which explicitly says behavior is
> undefined if data is null; the IDL for bufferData doesn't allow a null data
> argument, though).

The main question here is one of compatibility; would throwing a
TypeError instead of generating an INVALID_VALUE OpenGL error (which
some WebGL implementations do) break a significant number of web
pages? The answer is probably no, so most likely bufferData should not
accept nullable arguments. This question, however, is already being
actively discussed on something like two other email threads so let's
continue this conversation there.


You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list