W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 27 Jan 2012 18:43:54 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1201271836430.16982@ps20323.dreamhostps.com>
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.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 27 January 2012 10:43:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC