-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API for reading/writing binary data from/to Wasm memory #2035
Comments
I believe it's somehow addressed by #2442. Is it enough for you or do you need more? |
I never worked with
But I guess I missed something here. |
You're correct. We will provide a better API to solve your needs :-). |
Hey there! Great to see this moving in the board. The ticket was moved to Ready to Merge and 🎉 Done but there is not PR linked. Is it done and can be closed? |
The API for accessing memory was redone in #2646 but since this is a breaking change we are going to release it as part of Wasmer 3.0. We also have a bunch of other changes coming up which will improve the API. |
Great, thanks. Looking forward to it. |
Do I understand correctly this ticket is done by introducing WasmSlice in Wasmer 3.x? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Motivation
Reading raw binary data from Wasm memory and writing binary data to Wasm memory seems to be common use case of WasmPtr. Right now there is no clean API to do that without looping through a slice of
Cell<u8>
. Users have the desire (1, 2) to replace this loop with a more efficient way to copy chunks of memory, like std::ptr::copy or std::ptr::copy_nonoverlapping.Right now, users have two choices after calling
WasmPtr::<u8, Array>::new(..)deref()
:&[Cell<u8>]
for reading and writingCell
and slice, writing unsafe code that might work but is hard to understand and maintain. It took me more than an hour to convince myself what the layout of&[Cell<u8>]
looks like and it included reading Rust std source code.Proposed solution
Add an API to
WasmPtr
that allows reading raw binary data from Wasm memory and an API that allows writing raw binary data to Wasm memory. This can be similar to WasmPtr::get_utf8_str and probably share 9 of its 10 line implementation.This API can be
unsafe
but should take away as much of the burden from the user as possible.Alternatives
Not aware of any. Happy for input.
Additional context
This is us struggeling to go from choice 1 to choice 2 with our heads 🤯. I'm now convinced that
&[Cell<u8>]
has the same layout as&[u8]
but I don't want future readers of our code to go through this again (including me).The text was updated successfully, but these errors were encountered: