using int64 to pass cgo.Handle instead int

[buke]

#370

[qiuchengxuan]

You can cast pointer to double using math.Float64frombits to avoid performance loss

[buke]

I don't think using math.Float64frombits is good idea, cause float64 struct like this:
63 62────────52 51─────────────────────────────────0
│ │ │ │
│ │ │←─────── Mantissa(52) ────────→│
│ │
│ │←── Exponent(11)
│
└── Sign(1)
only 52bits to store value.

and cgo.Handle is uint64(64-bit), and all bits are used to store unsigned integer value .

[qiuchengxuan]

It's not type cast, actually is reinterpret uint64 as float64, no actual bit changes

[buke]

quickjs-go/context.go

Line 169 in 787d3db

val, err := ctx.Eval(`(proxy, fnHandler, ctx) => function() { return proxy.call(this, fnHandler, ctx, ...arguments); }`)

here using ctx.Eval to call js function , and cause I did not check quickjs c code ,I'm not sure whether quickjs does conversion

[qiuchengxuan]

Number in quickjs is either int32 or double, so your argument probably won't be converted, just need convert that double back to uintptr in goProxy

[buke]

yeah, and I found quicks support BigUint64 , https://github.com/bellard/quickjs/blob/6e2e68fd0896957f92eb6c242a2e048c1ef3cae0/quickjs.h#L549. I should using it instead string

[qiuchengxuan]

It's not easy to convert back

[buke]

I think the original implementation using ctx.Int64 to pass cgo.NewHandle is correct and safe. QuickJS's JS_NewInt64 function ensures that the full 64-bit integer value is preserved without any loss of precision or conversion to floating-point. This approach maintains the integrity of the handle value throughout the JavaScript-Go interaction.