W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

Re: [WebIDL] Behavior for negative values passed for unsigned arguments

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 14 Dec 2011 14:24:33 +1100
Message-ID: <4EE816F1.3000903@mcc.id.au>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: Jonas Sicking <jonas@sicking.cc>, public-script-coord@w3.org
Jonas Sicking:
>> Are there really any functions where we *want* unsigned values to
>> wrap? Either because it produces better behavior, or because it's
>> required for web compat?

Boris Zbarsky:
> For the former, probably not.
> For the latter, since none of the current UA stuff that uses unsigned
> ints throws on set, I would fully expect not throwing on at least some
> subset of those arguments and properties to be required for web compat...

I agree that wrapping is probably not what you want in nearly all cases. 
  I think moving to a world where [EnforceRange] is the default will 
need a lot of work to identify which existing attributes and operation 
arguments would require a [Wrap] on them.

If IndexedDB uses [EnforceRange] everywhere, without buy-in from other 
spec writers that that's what we should be doing from now on, then I 
feel like that's just helping to reduce what consistency we do have.

Changing the default to be [Clamp] would be a slightly easier change to 
make, given that it wouldn't cause an exception to be thrown.  There 
could well be content whose behaviour would still change when negative 
values passed as unsigned longs get interpreted as 0 instead of some 
large positive number.  So I think it would still require a bunch of 
research to find out where we'd need to specify [Wrap].

I think we need more agreement that either of these is the direction we 
want to move the platform to before we make changes to Web IDL.

So for now I am not making any change.  Jonas, for the Disposition of 
Comments document, please indicate whether this resolution is satisfactory.


Received on Wednesday, 14 December 2011 03:25:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC