478804 - Number toExponential() with no arguments returns truncated value.

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect, P2)

Description

[Jeff Dyer]

as:
var x = 77.1234;
print(x.toExponential());

Actual Results:
returns 7e+1

Expected Results:
7.71234e+1

Spidermonkey also returns 7.71234e+1

Workaround: Specify fractionDigits explicitly.
        
Transferred Comments:

BugDB Migration - Mon Jun 04 12:32:45 CDT 2007
[cpeyer 10/20/06] Entered Bug.

JIRA Migration Admin - Mon Jun 04 12:32:45 CDT 2007
Milestone ID = 1378
Milestone = FP 10 - Code Complete
Build ID = 22846
Build = AVMPLUS_1_0_0_d686
Fix Build ID = null
Fix Build = null


JIRA Migration Admin - Mon Jun 04 12:32:45 CDT 2007
Move from BugDB issue number 188971

Trevor Baker - Tue Jan 27 16:03:35 CST 2009
back to internal review for reprioritization


This bug transferred from: http://bugs.adobe.com/jira/browse/ASC-2256

Comment 1

[Michael Daumling]

This bug would require a fix in three places:

1) In Number.as, the default argument of toExponential is 0 instead of undefined (see ECMA-262, 15.7.4.6).

2) NumberClass::_convert() needs to take an Undefined argument into account - the "precision" argument probably needs to be an Atom instead of an integer.

3) MathUtils::convertDoubleToString() currently only removes trailing zeroes for the "normal" mode. It needs to do so for Exponential mode as well if the precision is Undefined.

I can take this bug if requested.

Comment 2

[Lars T Hansen]

TC pushed: redux changeset:   2760:2e75d5d3010b

Comment 3

[Lars T Hansen]

The patch for bug #521772 fixes this bug too.

Comment 4

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.