Hector Martin

yeah, you can, and you can also get rounding errors based entirely on the engine... you can't do that in production, so most don't consider it an option

No, you cannot get "rounding errors based on the engine". IEEE 754 is *precisely* defined. The *same* integers are, or aren't, representable in *every single system using IEEE 754". The only problem here is toString rounds some integers to impossible ones for no reason.

you think every implementation follows the spec properly? this is web browsers; today doesn't apply to last decade, where the constraints existed

IEEE 754 predates web browsers. It came out in 1985. And besides, IEEE 754 is baked into CPUs anyway, so browsers aren't going to randomly mess it up. The only problem here is JS *lies* when converting to a string.

No other programming language does this. No other programming language takes a floating-point value representing an integer, and, when converting it to a string, says "you know what, I'm going to give you a different integer, without any indication that rounding has occurred".

yeah, i know. i've been dealing with the oddness since the beginning... i'm not trying to defend it, just tried to point you at the 'why'. v8 has bigint now, and so does node 10.4.x afaik, so things are getting better (slowly, very slowly)

Yes, and hilariously, (4611686018427387904).toString() is "4611686018427388000" (the wrong answer), while BigInt(4611686018427388000).toString() is "4611686018427387904" (the right answer) (or it will be once Chrome catches up with the spec, right now it's an error).

try `0x4000000000000000n` ;) ... the 'n' is important atm