W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] number-related feedback

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 31 Dec 2008 03:59:50 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0812310357450.25317@hixie.dreamhostps.com>
On Wed, 31 Dec 2008, Jonas Sicking wrote:
> On Wed, Dec 31, 2008 at 3:17 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> > On Mon, Dec 29, 2008 at 11:37 AM, Ian Hickson <ian at hixie.ch> wrote:
> >> On Fri, 22 Aug 2008, Shannon wrote:
> >>> Either way I would recommend making a decision on minimum and maximum
> >>> integer values an using them consistently. If not I can imagine the
> >>> rapid adoption of 64-bit systems will cause unexpected errors when the
> >>> same code is run on older 32-bit systems. There are valid arguments for
> >>> letting each system use its native integer but if this is the case then
> >>> perhaps the spec should require MIN_INT and MAX_INT be made available as
> >>> constants.
> >>
> >> ECMAScript does define a range, and the limits of that range are exposed
> >> to scripts. Are there cases where there are non-script limits that would
> >> benefit from being exposed? Use cases would be helpful here.
> >
> > I thought ECMAScript defined the value to be a IEEE 754 64bit float.
> 
> Ah, sorry, I missed that you didn't have a 'not' in your response :)
> 
> There are in fact interop issues given the fact that ECMAScript allows
> for a range bigger than a 32bit integer can fit. For example you could
> do
> 
> myInput.maxLength = 5000000000;
> 
> This would is within the bounds and precision of ECMAScript, but won't 
> work in a 32bit integer implementation.

WebIDL defines how to handle that, though, right? (Each DOM attribute has 
an explicit bit width.) The problem, if there is a problem, would be with 
the content attribute alone.

-- 
Ian Hickson
Received on Tuesday, 30 December 2008 19:59:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC