551900 - Wrong conversion handling negative hexadecimal numbers parsed from string: '-0xFF' -> -255

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Eduardo Lundgren]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

On Firefox (< 3.6) the conversion from string representing negative hexadecimals numbers (from '-0xFF') were parsing correctly (to -255).

    Number('-0xFF') // -255 (correct)
    +('-0xFF') // -255 (correct)

Although, on Firefox 3.6 it's behaving differently:

    Number('-0xFF') // NaN (wrong conversion)
    +('-0xFF') // NaN (wrong conversion)

The conversion from non-string values is still working correctly:

    Number(-0xFF) // -255
    +(-0xFF) // -255



Reproducible: Always

Steps to Reproduce:
1. On Firefox 3.6 create a JavaScript to execute the following code: Number('-0xFF') or +('-0xFF')
2. The test should return -255 (Negative hexadecimal conversion from string)
3. This will return NaN instead
Actual Results:  
Number('-0xFF') // NaN (wrong conversion)
+('-0xFF') // NaN (wrong conversion)

Expected Results:  
Number('-0xFF') // -255 (correct)
+('-0xFF') // -255 (correct)

Comment 1

[Andreas Gal :gal]

javascript:alert(+('-0xFF')) gives NaN for me in Safari.

Comment 2

[Bob Clary [:bc] (inactive)]

should have been covered in ecma/TypeConversion/9.3.1-{1..3}.js

Comment 3

[Boris Zbarsky [:bzbarsky]]

See bug 273467.  The correct behavior per spec is to give NaN in these cases; the fact that -255 was returned before 1.9.2 was a bug.

Comment 4

[Eduardo Lundgren]

On Chrome on IE it's return -255 also.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sounds like Chrome is buggy.  So is Opera; I just checked.  Feel free to report the bugs to them.

IE8 does the same thing we do (returns NaN).

Comment 6

[Eduardo Lundgren]

Where exactly on the ECMAScript specification on the item 9.3.1 says that the grammar for ToNumber does not permit hex integer literals to be signed?

What this logic is applied only for hexadecimals?

Note:
   +'-1' // -1
   +'+1' // 1
   +'-0x1' // NaN
   +'+0x1' // NaN

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Where exactly on the ECMAScript specification on the item 9.3.1 says that the
> grammar for ToNumber does not permit hex integer literals to be signed?

Right at the beginning of the section:

  9.3.1 ToNumber Applied to the String Type 

  ToNumber applied to Strings applies the following grammar to the input
  String. If the grammar cannot interpret the String as an expansion of
  StringNumericLiteral, then the result of ToNumber is NaN. 

The grammar has:

  StrNumericLiteral ::: 
    StrDecimalLiteral 
    HexIntegerLiteral 

  HexIntegerLiteral ::: 
    0x HexDigit 
    0X HexDigit 
    HexIntegerLiteral HexDigit 

Not that a HexIntegerLiteral cannot start with '-' per this grammar.

> What this logic is applied only for hexadecimals?

That's correct.  From the same grammar:

  StrDecimalLiteral ::: 
    StrUnsignedDecimalLiteral 
    + StrUnsignedDecimalLiteral 
    - StrUnsignedDecimalLiteral

Comment 8

[Eduardo Lundgren]

Based on the spec you guys are right.

But I still do not understand why the spec doesn't allow the signed from hexa. If support '-1' and '0xFF' then they should support '-0xFF'. Why the parseInt supports it and the ToNumber don't?


I appreciate the help. Thank you.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> But I still do not understand why the spec doesn't allow the signed from hexa.

That's something to ask the ECMA committee.

Comment 10

[Brendan Eich [:brendan]]

Eduardo: if you subscribe by mailing "subscribe" in the subject or body to [e-mail], then you can raise this issue on the mailing list we on Ecma TC39 use, along with a great many JS hackers, implementors, and onlookers: [e-mail].

/be