430427 - ecma/Array/15.4.4.5-3.js test fails in GMT(BST) time zone

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Alexey Proskuryakov]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; ru-ru) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.18
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; ru; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

This test verifies how sorting works. In GMT time zone, the array being sorted happens to contain two instances of the same date (Jan 01 2000), but Array.sort() is not guaranteed to be stable by ECMA-262, and different Date objects don't compare as equal even if the dates are the same.

This was originally reported as <https://bugs.webkit.org/show_bug.cgi?id=18687>.

Reproducible: Always

Comment 1

[Alexey Proskuryakov]

Attachment: standalone test case

A standalone test case derived from ecma/Array/15.4.4.5-3.js.

Comment 2

[x0]

comparefn3 isn't a consistent comparison function, so the behavior of sort is implementation-defined (i.e. may give any result) per ECMA3 15.4.4.11.

function comparefn3( x, y ) {
    return ( x == y ? 0 : ( x > y ? 1: -1 ) );
}

For two different Date objects a and b that refer to the same time value, a == b will be false, a > b will be false, and b > a will be false, but a == a is true. Thus, a <CF b and b <CF a, but not a <CF a, so transitivity of <CF is violated.

Note that relational operators convert objects to number (or string), but equality operators do not. |new Date(v) == new Date(v)| will always be false.

Comment 3

[Alexey Proskuryakov]

It looks like stringsort from the original test could use some improvement, too.

Comment 4

[x0]

Actually, the testcase doesn't fail with a trunk build, but fails with older builds (although jsDriver.pl doesn't detect the failure, see bug 430509).

It succeeds also with older builds if I change comparefn3 to

function comparefn3( x, y ) {
  return ( +x == +y ? 0 : ( x > y ? 1 : -1 ) );
}

Then comparefn3 should be equivalent to realsort and both arrays sorted identically, even if the sort isn't stable (although ECMA doesn't guarantee a deterministic order).

Comment 5

[Brian Crowder]

This does seem to work on trunk, currently.

Comment 6

[Jakob Gruber]

This test is still broken, as explained in comment 2 above. Sort order is implementation defined if the comparison function is inconsistent.

comparefn3() is inconsistent. The reference comparison function realsort() is not. It's a matter of luck if this test succeeds or not.

The proper fix is probably just to remove testarr3 / comparefn3. Even if fixed, I don't think it adds any value over realsort since the '>' operator also ends up calling valueof().

See also the related V8 bug report: https://crbug.com/v8/8146