Closed Bug 430427 Opened 14 years ago Closed 13 years ago

ecma/Array/ test fails in GMT(BST) time zone


(Core :: JavaScript Engine, defect)

Not set





(Reporter: ap, Unassigned)


(Keywords: testcase)


(1 file)

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: Gecko/20080201 Firefox/

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 <>.

Reproducible: Always
Attached file standalone test case
A standalone test case derived from ecma/Array/
Assignee: nobody → general
Component: Testing → JavaScript Engine
Keywords: testcase
QA Contact: testing → general
comparefn3 isn't a consistent comparison function, so the behavior of sort is implementation-defined (i.e. may give any result) per ECMA3

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.
It looks like stringsort from the original test could use some improvement, too.
Actually, the testcase doesn't fail with a trunk build, but fails with older builds (although 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).
Ever confirmed: true
This does seem to work on trunk, currently.
Closed: 13 years ago
Resolution: --- → WORKSFORME
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:
You need to log in before you can comment on or make changes to this bug.