1958820 - %TypedArray%.prototype.sort should always normalise NaN values

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect, P3)

Description

[Aapo Alasuutari]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Run the following script:

b = BigUint64Array.of(9221120237041091055n, 9221120237041090774n);
console.log(b[0], b[1]);
a = new Float64Array(b.buffer);
a.sort();
console.log(b[0], b[1]);
a.sort(() => Math.random() ? -1 : 1);
console.log(b[0], b[1]);

Actual results:

Output:

9221120237041091055n 9221120237041090774n
9221120237041090774n 9221120237041091055n
9221120237041090560n 9221120237041090560n

When calling %TypedArray%.prototype.sort with no comparator, Firefox performs sorting of floating point values according to some unknown ordering. When calling the method with a comparator function, Firefox normalises the NaN values.

Expected results:

Output:

9221120237041091055n 9221120237041090774n
9221120237041090560n 9221120237041090560n
9221120237041090560n 9221120237041090560n

Calling sort should always normalise NaN values, regardless of the comparator function being present or not. The specification defines sort as reading all values from the source buffer, converting them to JavaScript Values, sorting those, and finally writing them back into the source buffer. When converting to JavaScript Values, all floating point NaN must be canonicalised.

Comment 1

[André Bargull [:anba]]

ECMA-262 and implementations don't quite agree on NaN canonicalisation, see:

• https://github.com/tc39/ecma262/issues/635
• https://github.com/tc39/ecma262/pull/758

For performance reasons it's preferable do to less NaN canonicalisation (bug 932767). JSC also recently changed their implementation to perform fewer NaN canonicalisations. V8 doesn't use NaN boxing, so they never had to perform NaN canonicalisation.

Comment 2

[Aapo Alasuutari]

Some more discussion was had in TC39 Matrix and it was suggested (though of course not yet accepted in a meeting) that the entire language regarding mention of "always choose the same encoding for each implementation distinguishable NaN value" should be removed entirely. With that, I believe, this bug also becomes fully not-a-bug (and I'm not even sure if this is a bug now, with some better reading comprehension).

So, I'll close this.