Hector Martin

Js follows IEEE 754, quite sure that's expected behaviour

Nope, it doesn't. This is *specified* in IEEE 754. JS is violating the spec.https://twitter.com/marcan42/status/1009008156322623489 …

I think you’re confused about what double-precision floating-point means. See: https://tc39.github.io/ecma262/#sec-ecmascript-language-types-number-type … https://en.wikipedia.org/wiki/Double-precision_floating-point_format#IEEE_754_double-precision_binary_floating-point_format:_binary64 … https://developers.google.com/web/updates/2018/05/bigint … https://mathiasbynens.be/demo/integer-range … For integers, JavaScript uses 53 bits to store the digits and + 1 for the sign.

I think you're confused about what "integer" means. The 64-bit IEEE754 floating point value represented by the (big-endian) bytes 43d0000000000000 *represents* the int 4611686018427387904. It does *not* represent the int 4611686018427388000. The latter is not representable.

You can *round* 4611686018427388000 to the nearest representable integer in that format, which is 4611686018427387904. But there is no reason to conjure up 4611686018427388000 when converting back to integer. That is just wrong and broken.

Yes, the ECMAScript spec says toString must be implemented in this (broken) way. This is insane, and no other sensible language does this. It is misleading and wrong. https://tc39.github.io/ecma262/#sec-tostring-applied-to-the-number-type …

Ultimately this is a problem of the principle of least surprise. To any reasonable human, a string of digits with no decimal point is an *integer*. However, to JavaScript, it's a *float*. JS is abusing this point to produce unexpected results from toString.