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

On Tue, Dec 13, 2011 at 7:24 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

I'm not convinced that IndexedDB using [EnforceRange] decreases any
meaningful consistency. Various functions are quite different and
already throws under different conditions. For example 100% of the
indexedDB functions which takes numerical values (i.e. both of the 2
we have) throws not just for negative values, but also for 0.

I'm happy to leave WebIDL as it currently is. If we feel that it's
important for sanity or consistency to change various APIs which
currently wrap to throw, then we can do so with no action needed from
WebIDL.

At worst we'll end up sprinkling more [EnforceRange] or [Clamp] around
specs than we otherwise would have, which doesn't seem like a big
deal.

So yes, I'm ok with this resolution.

/ Jonas

Received on Wednesday, 14 December 2011 03:36:08 UTC