[Gnash-dev] Broken NaN comparison in Ecma-262

[Eric Hughes]

Moved over from gnash-commit.

At 06:54 AM 7/9/2007, strk wrote:
> In these cases we should refer to an higher standard (ECMA-262 in this case)
> and properly document the differences. Other opinions are welcome.

You got me curious.  Here's the short version.  IEEE got it right, then 
Ecma got it wrong, which boggles, since they make explicit reference to IEEE.

Here's a quotation from the most recent draft of IEEE 754r:
> Comparisons are exact and never overflow or underflow. Four mutually 
> exclusive relations are possible: less
> than, equal, greater than, and unordered. The last case arises when at 
> least one operand is NaN. Every NaN
> shall compare unordered with everything, including itself.

Here's an excerpt from Ecma-262, 3rd Edition.  Step 5 returns undefined if 
either operand is NaN.  Pay attention to step 6.
> 11.8.2 The Greater-than Operator ( > )
> The production RelationalExpression : RelationalExpression > 
> ShiftExpression is evaluated as follows:
> 1. Evaluate RelationalExpression.
> 2. Call GetValue(Result(1)).
> 3. Evaluate ShiftExpression.
> 4. Call GetValue(Result(3)).
> 5. Perform the comparison Result(4) < Result(2). (see 11.8.5).
> 6. If Result(5) is undefined, return false. Otherwise, return Result(5).

In short, Ecma-262-3rd is broken.  Make of that what you will.  It's 
possible that 4th-edition may not be completely broken, the draft does not 
yet contain the broken algorithm.

It's possible the long-term requirement will be to provide version-specific 
behavior.

Eric