minification of number literals works differently on arm64 and 64 platforms

[pirxpilot]

For arm64:

$ echo "x = 0xFFFF_FFFF_FFFF_FFFF" |  esbuild --minify
x=0xffffffffffffffff;

For 64:

$ echo "x = 0xFFFF_FFFF_FFFF_FFFF" |  esbuild --minify
x=18446744073709552e3;

Obviously not that important. Stumbled upon it while bundling mapbox/pbf
Potentially related to #2162 fix?

[evanw]

Thanks for the report. Here's a simple way to reproduce the underlying problem:

package main

import (
	"fmt"
	"runtime"
	"unsafe"
)

func main() {
	var x float64 = 0xffff_ffff_ffff_ffff
	var y uint64 = uint64(x)
	fmt.Printf("GOARCH %s, x %v (0x%016x), y 0x%016x\n", runtime.GOARCH, x, *(*uint64)(unsafe.Pointer(&x)), y)
}

On arm64 that prints this:

GOARCH arm64, x 1.8446744073709552e+19 (0x43f0000000000000), y 0xffffffffffffffff

and on amd64 that prints this:

GOARCH amd64, x 1.8446744073709552e+19 (0x43f0000000000000), y 0x8000000000000000

The Go specification says this:

In all non-constant conversions involving floating-point or complex values, if the result type cannot represent the value the conversion succeeds but the result value is implementation-dependent.

The problem is that 1.8446744073709552e+19 is 18,446,744,073,709,552,000 which is 0x1_0000_0000_0000_0180 (i.e. Go rounds the 0xffff_ffff_ffff_ffff literal up instead of down when converting to float64, which then doesn't fit back into uint64).

Maybe the safest upper limit to use is 18,446,744,073,709,550,000 which is 0xffff_ffff_ffff_f800. That's the next lowest 64-bit floating-point number, and the first one that is under 0xffff_ffff_ffff_ffff and representable as uint64.