Re: Observability of NaN distinctions — is this a concern?

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Mon Mar 25 23:40:17 PDT 2013


On Tue, Mar 26, 2013 at 4:16 AM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Mar 26, 2013, at 2:35 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
> wrote:
>
> >
> > On Mar 25, 2013, at 6:00 PM, Brendan Eich wrote:
> >
> >> Right, thanks for the reminder. It all comes back now, including the
> "how to write correct ending-independent typed array code" bit.
> >
> > Ok, so looping back to my earlier observation.  It sounds like
> endian-ness can be observed by writing into an Float64Array element and
> then reading back from a Uint8Array that is backed by the same buffer.  If
> there is agreement that this doesn't represent a significant
> interoperability hazard can we also agree that not doing NaN
> cannonicalization on writes to FloatXArray is an even less significant
> hazard and need not be mandated?
> >
>
> The reason I have pushed for NaN canonicalization is because it means that
> it allows (and in essence requires) that typedArray[n] = typedArray[n] can
> modify the bit value of typedArray[n].
>
> An implementation _may_ be able to optimize the checks away in some cases,
> but most engines must perform checks on read unless they can prove that
> they were the original source of the value being read.
>
> Forcing canonicalization simply means that you are guaranteed that a
> certain behavior will occur, and so won't be bitten by some tests changing
> behavior that you may have seen during testing.  I know Ken hates these
> sorts of things, but seriously in the absence of a real benchmark, that
> shows catastrophic performance degradation due to this, simply saying "this
> is extra work that will burn cpu cycles" without evidence is a waste of
> time.


I also disagree with you.


> Also there is absolutely no case in which abstract performance concerns
> should ever outweigh absolute security and correctness bugs.
>

Could you elaborate on the security part? I doubt NaN distinctions can
really be of any significant use for fingerprinting, etc.

So far I've yet to come across any unexpected bugs caused by this, maybe
you have examples? NaN is usually a non-desired value so if you write a NaN
you probably had a bug in the first place.

And about correctness, by definition NaN is a category, not a value; by
definition a NaN value is not the same as another NaN value. If you want to
canonicalize NaN, my suggestion is IEEE, not ES-discuss. ;)


> We need to stop raising "this causes performance problems" type issues
> without a concrete example of that problem.  I remember having to work very
> hard to stop WebGL from being a gaping security hole in the first place and
> it's disappointing to see these same issues being re-raised in a different
> forum to try and get them bypassed here.
>

Before saying security hole, please elaborate. Also, when it comes to
standards, I think change should be justified with data, rather than the
other way around.

Cheers,
Jussi


> --Oliver
>
> > Allen
> >
> >
> >
> >
> >>
> >> /be
> >>
> >> On Mar 25, 2013, at 4:33 PM, Kenneth Russell <kbr at google.com> wrote:
> >>
> >>> On Mon, Mar 25, 2013 at 4:23 PM, Brendan Eich <brendan at mozilla.com>
> wrote:
> >>>> Allen Wirfs-Brock wrote:
> >>>>>
> >>>>> On Mar 25, 2013, at 4:05 PM, Brendan Eich wrote:
> >>>>>
> >>>>>> Allen Wirfs-Brock wrote:
> >>>>>>>
> >>>>>>> BTW, isn't cannonicalization of endian-ness for both integers and
> floats
> >>>>>>> a bigger interop issue than NaN cannonicalization?  I know this was
> >>>>>>> discussed in the past, but it doesn't seem to be covered in the
> latest
> >>>>>>> Khronos spec.  Was there ever a resolution as to whether or not
> TypedArray
> >>>>>>> [[Set]] operations need to use a cannonical endian-ness?
> >>>>>>
> >>>>>> Search for "byte order" at
> >>>>>> https://www.khronos.org/registry/typedarray/specs/latest/.
> >>>>>
> >>>>>
> >>>>> I had already search for "endian" with similar results.  It says
> that the
> >>>>> default for DataViews gets/sets that do not specify a byte order is
> >>>>> big-endean. It doesn't say anything (that I can find) about such
> accesses on
> >>>>> TypedArray gets/sets.
> >>>>
> >>>>
> >>>> Oh, odd -- I recall that it used to say little-endian. Typed arrays
> are LE
> >>>> to match dominant architectures, while DataViews are BE to match
> packed
> >>>> serialization use-cases.
> >>>>
> >>>> Ken, did something get edited out?
> >>>
> >>> No. The typed array views (everything except DataView) have used the
> >>> host machine's endianness from day one by design -- although the typed
> >>> array spec does not state this explicitly. If desired, text can be
> >>> added to the specification to this effect. Any change in this behavior
> >>> will destroy the performance of APIs like WebGL and Web Audio on
> >>> big-endian architectures.
> >>>
> >>> Correctly written code works identically on big-endian and
> >>> little-endian architectures. See
> >>> http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ for a
> >>> detailed description of the usage of the APIs.
> >>>
> >>> DataView, which is designed for input/output, operates on data with a
> >>> specified endianness.
> >>>
> >>> -Ken
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130326/ce22e738/attachment-0001.html>


More information about the es-discuss mailing list