[whatwg] How should overflow be handled when parsing integers?
Ian Hickson
ian at hixie.ch
Fri Jan 27 10:43:54 PST 2012
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list