[whatwg] How should overflow be handled when parsing integers?

[Daniel Bates]

On Oct 16, 2011, at 11:02 AM, Mounir Lamouri wrote:

> On 10/16/2011 02:17 PM, Daniel Bates wrote:
>> How should overflow be handled when parsing integers?
>> 
>> Step 8 of the parsing algorithm in both<http://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers>  and<http://dev.w3.org/html5/spec/Overview.html#non-negative-integers>  doesn't mention how to handle integer overflow when interpreting the result of a sequence of base-ten integers.
>> 
>> Currently in WebKit we consider such overflow a parsing error. Is there any reason not to consider overflow a parsing error? Regardless, I suggest codifying the handling of overflow in the aforementioned sections.
> 
> Gecko also considers that an overflow is a parsing error. Presto and IE6 doesn't seem to.
> The specs should probably mention this by whether consider it as a parsing error or request the UA to default to the highest value (which Presto and IE6 seem to do but not using the same value).

Notice that spec tends to provide guidance when the rules for parsing a number return an error. For instance, the spec defines what happens when parsing the value of the tabindex attribute returns an error: <http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#sequential-focus-navigation-and-the-tabindex-attribute>.

I suggest that we return an error in step 8 of the rules for parsing signed/non-negative integers when the sequence of characters cannot be interpreted as an base-ten integer that is representable using an integer datatype. Then we can leave it up to the relevant sections of the spec to define how to handle such a parser error (like in the case for tabindex), including whether to fall back to an agreed default value or leave it up to the UA (which may default to the highest value).

> 
>> This issue came up recently in WebKit with respect to the parsing of the maxlength attribute (https://bugs.webkit.org/show_bug.cgi?id=68981).
> 
> Actually, this problem wouldn't have been that annoying if Webkit was following the specs regarding maxlength attribute: if the content attribute value isn't a valid non-negative integer, the element has no maximum allowed value length.

Thank you for bringing this up and directly commenting about this on the bug (https://bugs.webkit.org/show_bug.cgi?id=68981). Currently WebKit doesn't conform to this behavior. As mentioned by Kent Tamura on the bug, this issue is covered by WebKit bug #44883 (https://bugs.webkit.org/show_bug.cgi?id=44883).

Dan