Re: [whatwg] How should overflow be handled when parsing integers?
On Sun, 16 Oct 2011, Daniel Bates wrote: How should overflow be handled when parsing integers? Use more storage. :-) If that's inpractical due to hardware limitations (e.g. the architecture is optimised for integers in specific widths) then you can handle it pretty much how you like. Currently in WebKit we consider such overflow a parsing error. That's fine. I suggest codifying the handling of overflow in the aforementioned sections. Generally speaking we try not to overspecify the handling of situations that occur due to hardware limitations, because different architectures have different constraints. It's not such a big deal in parsing numbers into a fixed-width storage space, admittedly, but consider a UA that _does_ try to grow its storage space to store arbitrarily sized numbers, and runs out of memory when doing so. It might be impractical to do anything but fail with an exception at that point. In fact, depending on the architecture, it might be impractical to do anything but crash. On Sun, 16 Oct 2011, Mounir Lamouri wrote: 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). I would recommend ignoring the attribute entirely rather than using an arbitrarily high value, personally. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How should overflow be handled when parsing integers?
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 bothhttp://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers andhttp://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
[whatwg] How should overflow be handled when parsing integers?
(Please disregard this email if you already received a copy of it) 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. 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). Dan
Re: [whatwg] How should overflow be handled when parsing integers?
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 bothhttp://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers andhttp://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). 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. -- Mounir
