But note that if you have a use case which QuickJS supports and is currently not supported by rquickjs than I would appreciate it if you raised an issue for that use case. Ideally rquickjs should allow you to do anything QuickJS allows without having to fallback to the raw C library.
Looking through code from the time, for me it was direct / unsafe access to JS_NewArrayBuffer in a rather unusual scenario.
Main issue was that ArrayBuffer::{new, new_copy} currently both always clone data (although in different ways) but I needed it to point to an existing memory slice for sort of efficient mmap-ing.
JS_NewArrayBuffer supports mapping slices as it simply accepts pointer + length, but rquickjs' safe wrapper doesn't.
Perhaps this could even be done in a backward-compatible way where ArrayBuffer::new would instead accept any AsRef<[u8]> and drop it in the end like it currently drops the vector, so that drop would get compiled to no-op for static slices, but would remain real drop for vectors, Box<[u8]>, Rc<[u8]> and such.
Following up to:
Looking through code from the time, for me it was direct / unsafe access to
JS_NewArrayBufferin a rather unusual scenario.Main issue was that
ArrayBuffer::{new, new_copy}currently both always clone data (although in different ways) but I needed it to point to an existing memory slice for sort of efficient mmap-ing.JS_NewArrayBuffersupports mapping slices as it simply accepts pointer + length, but rquickjs' safe wrapper doesn't.Perhaps this could even be done in a backward-compatible way where
ArrayBuffer::newwould instead accept anyAsRef<[u8]>and drop it in the end like it currently drops the vector, so that drop would get compiled to no-op for static slices, but would remain real drop for vectors,Box<[u8]>,Rc<[u8]>and such.