W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2012

Re: Unrestricted float

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 09 Apr 2012 10:43:16 +1000
Message-ID: <4F8230A4.90600@mcc.id.au>
To: Brendan Eich <brendan@mozilla.org>
CC: Anne van Kesteren <annevk@opera.com>, public-script-coord@w3.org
Brendan Eich:
> Can someone take a census?

 From my local copies of IDL from specs copied a couple of months ago:

HTML Media Capture

(writable) attribute MediaFileData.duration
Not clear to me that the attributes on MediaFileData are meant to be 
writable in the first place; the spec does not say what writing to them 


elementFromPoint() and caretPositionFromPoint()
Don't say what to do when a non-finite value is passed.

readonly attributes on ClientRect
Looks like they always return finite values.

DOM 3 Events

readonly attributes WheelEvent.delta{X,Y,Z}
Seem to be always finite values.

CSS 3D Transforms

(writable) attributes CSSMatrix.{[a-f],m[1-4][1-4]} and the transform, 
scale, rotate, rotateAxisAngle operations on CSSMatrix.
Seem to be finite values.  Spec does not say what to do if non-finite 
values are passed to scale, rotate, etc.

Geolocation API

readonly attributes latitude, longitude, etc. on Coordinates
All look to be finite except for the heading attribute, which can be NaN.


The general text here at least makes it defined what happens when a 
non-finite value is passed in:

   Except where otherwise specified, if an IDL attribute that is a
   floating point number type (double) is assigned an Infinity or Not-a-
   Number (NaN) value, a NotSupportedError exception must be thrown.

   Except where otherwise specified, if a method with an argument that
   is a floating point number type (double) is passed an Infinity or
   Not-a-Number (NaN) value, a NotSupportedError exception must be


attributes on HTMLMediaElement
(readonly) duration can be NaN.

(writable) attribute HTMLInputElement.valueAsNumber
Can return NaN.

A bunch of the canvas APIs treat NaN and infinities differently, by for 
example ignoring their assignment or operation call or throwing a 
particular exception.

All the remaining APIs don't seem to return non-finite values, and get 
caught by the general text above to prevent non-finite values from 
getting through.

Typed Arrays

As Anne says I think the Float/Double array view interfaces expect to 
see all kinds of values.  (Never mind the fact that only a single NaN 
can ever be exposed to JS.)


The spec doesn't say what to do with non-finite values at all, currently.

> Anyway, even with the majority favoring 'restricted', it's a bit of a
> mind-trap for anyone coming from C and similar languages.

Verbosity and the fact that the majority favour restricted were the 
reasons for making "unrestricted" explicit, yes.  But I think having 
"rfloat" and "rdouble" would be more odd.

I'm kind of fond of NaNs and ┬▒Infinity.  I'm not convinced introducing 
"unrestricted" was the right decision, but it at least plugs some 
undefined behaviour holes, for cases where spec writers forget to worry 
about these values.

Here is the bug that introduced "unrestricted" btw:

Received on Monday, 9 April 2012 00:43:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:47 UTC