2 years ago
a year ago


(Reporter: jmichae3, Unassigned)





2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170809080026

Steps to reproduce:

in console or js run:

Actual results:

wrong number, should be 0. for some reason, parseInt took the leftmost digit of a float and returned it even though the exponent is -7.

Expected results:

should have returned 0.

Comment 1

2 years ago
this bug is in opera as well, so may be in spec.
parseInt receives string as the first argument, and stops parsing at '.',
so whether it has "e-7" at the end or not doesn't matter.

if you want to parse such syntax, you need parseFloat instead.
Last Resolved: 2 years ago
Resolution: --- → INVALID
or perhaps what you need might be just Math.{round,floor,ceil}

Comment 4

2 years ago
no, parseInt used to correctly convert floating point to an integer. correct result is 0. this is all wrong. that behavior breaks a LOT of old code.

the correct behavior for floating point I think looked something like:
function parseInt(floatingPointValue) {
if (typeof(floatingPointValue)=="string") convert string to number;
if (floatingPointValue>Math.pow(2,53)) return NaN;
if (floatingPointValue>=0&&floatingPointValue<1) return 0;//[0..1)
if (floatingPointValue>=-1&&floatingPointValue<0) return -1;//[-1..0)
return INT(floatingPointValue);

Comment 5

2 years ago
the spec is broken.

Comment 6

2 years ago
by the way, ceil and round does not replace an integerize function like parseInt(), which is suppose to "leave off everything past the decimal point." so to speak. technically that cannot be done as a correct measure for an INT() function. C++ does not do the spec method when you perform a type conversion to int using int(double). maybe it should be bought/permissioned. I don't know how they lost its goodness.

I am going to leave off of this until it gets fixed.
Component: Untriaged → JavaScript Engine
Product: Firefox → Core

Comment 7

a year ago
I must say, I used the words myself "everything past the decimal point" regarding parseInt, and someone implemented it, now I feel bad because that's not the algorithm. and it's still broken in current stable ff.
I do not know exactly what the correct algorithm is, but it can be thought out. and an older spec had the correct algorithm - the one used 2 months ago at least, before all the code breakage it's causing.

if someone is using integers for fixed point e-commerce like I think, it would be a very notable bug. thank you for fixing the bug.

Comment 8

a year ago
Math.floor always returns input-1 or input as integer. 
Math.ceil always returns input+1 or input as integer.
these are not to be confused with parseInt(), which are the *only* int() (integerize) function that simply drops non-integer parts. just to make this clear. not sure what parseInt used to do with something > mantissa size though. I think it simply returned the floating point number at that point (anything over about 2^53).
Component: JavaScript Engine → General
Product: Core → Invalid Bugs
Version: 55 Branch → unspecified
(In reply to Jim Michaels from comment #7)
> an older spec had the correct algorithm - the one used 2 months ago
> at least, before all the code breakage it's causing.

parseInt behavior has not changed for years, at least when it comes to this.

(In reply to Jim Michaels from comment #5)
> the spec is broken.

Maybe it is, maybe it's not. There are a lot of things in the spec that are not great, but we do have to implement the spec, so Bugzilla is really not the right place to discuss this. We've told you this before.
You need to log in before you can comment on or make changes to this bug.