Bug 25027 - JavaScript parseInt wrong on negative numbers
Summary: JavaScript parseInt wrong on negative numbers
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 25478 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-03 08:16 PDT by Mihnea Ovidenie
Modified: 2009-04-30 02:09 PDT (History)
1 user (show)

See Also:


Attachments
Simple patch for the issue (2.81 KB, patch)
2009-04-04 00:58 PDT, Mihnea Ovidenie
sam: review-
Details | Formatted Diff | Diff
Patch following coding style rules (2.82 KB, patch)
2009-04-08 00:19 PDT, Mihnea Ovidenie
oliver: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mihnea Ovidenie 2009-04-03 08:16:35 PDT
Hello,

I used a simple test script for JavaScript parseInt function:
<html>
<head>
  <script>
  function testParseInt() {
  	var result = -0.6;
  	alert(parseInt(result));
  }
  </script>
</head>
<body>
<input type="button" onclick="testParseInt()" value="TestEval1">
</body>
</html>

However, instead of displaying 0, it display -1. The problem seems to be in:
JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp function globalFuncParseInt at line:

        if (isfinite(d))
            return jsNumber(exec, floor(d));

I think it should be:
        if (isfinite(d))
            return jsNumber(exec, (d > 0) ? floor(d) : ceil(d));

I tested with latest WebKit build 42198 on Leopard and the alert displays -1 instead of 0.
FF3/Opera/IE8(Win) display 0 on the same test.

I can provide a patch but i was not sure where to put the layout test. Is it ok to change LayoutTests/fast/js/numeric-conversion-expected by adding test for this case or should i add another different unit test?

Regards,
Mihnea
Comment 1 Mihnea Ovidenie 2009-04-04 00:58:45 PDT
Created attachment 29250 [details]
Simple patch for the issue

Hello,
I created the patch and added a simple test for the issue in LayoutTests/fast/js/numeric-conversion test.
Regards,
Mihnea
Comment 2 Sam Weinig 2009-04-06 11:50:23 PDT
Comment on attachment 29250 [details]
Simple patch for the issue

> -            return jsNumber(exec, floor(d));
> +            return jsNumber(exec, (d > 0)?floor(d):ceil(d));

Our style dictates that there should be spaces around the ? and :
Comment 3 Mihnea Ovidenie 2009-04-08 00:19:41 PDT
Created attachment 29325 [details]
Patch following coding style rules

Hello,
I corrected the coding style and posted the patch again. Thanks for your comments. I will try to double check from now on the coding style before submitting a patch. I was mislead by the fact that in Xcode project i had formatted the code in appropriate style, while the script svn-create-patch somehow removed the spaces. 
Regards,
Mihnea
Comment 4 Oliver Hunt 2009-04-16 23:59:11 PDT
Comment on attachment 29325 [details]
Patch following coding style rules

r=me! will land shortly
Comment 5 Oliver Hunt 2009-04-17 00:38:00 PDT
Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	JavaScriptCore/ChangeLog
	M	JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
	M	LayoutTests/ChangeLog
	M	LayoutTests/fast/js/numeric-conversion-expected.txt
	M	LayoutTests/fast/js/resources/numeric-conversion.js
Committed r42607
Comment 6 Julien Dufrenne 2009-04-30 02:09:30 PDT
*** Bug 25478 has been marked as a duplicate of this bug. ***