§4.2.9: conversion to unsigned long and bounds checking

WebIDL says that values are converted to unsigned long with ToNumber and 
ToUint32().  If I understand correctly, small negative values wrap 
around and become large positive values without throwing any error.  Why 
not throw a TypeError here if someone passes a negative number to a 
method declared to accept only positive numbers?  The ToNumber() 
conversion seems very JavaScripty and expected.  But wrapping does not.

As a concrete example, consider the DOM CharacterData.deleteData() 
method.  It takes two unsigned long arguments that specify the start and 
length of the data to be deleted.  The old DOM Core Level 2 spec says 
that the method should throw an exception if the second argument is 
negative, and Chrome and Safari do that.  The new DOM Core spec 
correctly recognizes that WebIDL does not allow the second argument to 
be negative, so it drops that provision.  Firefox follows the new spec: 
if you specify a second argument of -1, it deletes (2^32)-1 characters 
or (more likely) to the end of the string.

Firefox follows the newer specs, but frankly, the webkit behavior seems 
more useful here.

So, two questions:

1) Can WebIDL change to throw a TypeError on negative unsigned longs 
instead of wrapping them? (I don't know about out-of-bound longs--that 
problem seems less likely to arise in practice).

2) If not, how about defining a [CheckBounds] extended attribute that 
alters the numeric conversions (like the [Clamp] attribute already 
does), so that they do bounds checking?  Then, if DOMCore (for example) 
wanted to be more compatible with DOM Level 2, it could declare the 
deleteData method [CheckBounds]. Then it would throw a TypeError on 
negative arguments instead of a INDEX_SIZE_ERR DOMException, but at 
least it would throw rather than silently wrapping.

     David

Received on Thursday, 4 August 2011 22:59:41 UTC