Conversation
We don't really need 64bits to store them. See: https://bun.com/docs/runtime/ffi#pointers
|
x86_64 5-level page tables extend virtual addresses to 56 bits. Linux only hands out addresses < 2^48 for compatibility reasons but user space can mmap memory across the whole range (ref). |
|
Oh TIL! Hum, do you think it's worth to have the extra ergonomics of numbers or meh simply revert? |
|
That's up to you, of course. :-) You could support both bigints and numbers, maybe? For completeness' sake, arm64 supports 56 bits pointers through an extension but I don't know if any hardware exists yet that supports that. Arm64 with 52 bits pointers and memory tagging (MTE) also produces addresses that don't fit, but the process has to a) mmap memory with a special flag, and b) turn on protection with a prctl, so that's perhaps a non-issue for txiki.js. |
|
Thanks for the advice! I also considered "opaque" objects (a JSObject with a NULL prototype and the raw pointer in the opaque data) a la Python PyCapsule. Since the change won't be large either way I'm going to wait for the first breakage report :-) Thanks again, Ben! |
It's a thin object which stores a native pointer in its opaque field, similar to Python's PyCapsule: https://docs.python.org/3/c-api/capsule.html Turns out storing pointers as JS numbers is not that future-proof: #851 (comment) Thanks @bnoordhuis for the advice! In addition, introduce a `read` helper to be able to easily read data from a pointer a la Bun.
It's a thin object which stores a native pointer in its opaque field, similar to Python's PyCapsule: https://docs.python.org/3/c-api/capsule.html Turns out storing pointers as JS numbers is not that future-proof: #851 (comment) Thanks @bnoordhuis for the advice! In addition, introduce a `read` helper to be able to easily read data from a pointer a la Bun.
It's a thin object which stores a native pointer in its opaque field, similar to Python's PyCapsule: https://docs.python.org/3/c-api/capsule.html Turns out storing pointers as JS numbers is not that future-proof: #851 (comment) Thanks @bnoordhuis for the advice! In addition, introduce a `read` helper to be able to easily read data from a pointer a la Bun.
We don't really need 64bits to store them.
See: https://bun.com/docs/runtime/ffi#pointers