Skip to content
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

Can encoding instructions use memory as a scratch space? #39

Open
wingo opened this issue Jul 13, 2022 · 2 comments
Open

Can encoding instructions use memory as a scratch space? #39

wingo opened this issue Jul 13, 2022 · 2 comments

Comments

@wingo
Copy link
Collaborator

wingo commented Jul 13, 2022

If, in the implementation of stringrefs in your wasm VM, you have a managed buffer of WTF-8, and the user requests that you write UTF-8 to memory via string.encode_lossy_utf8, one tactic would be to just memcpy the whole thing, and then go back and change any surrogate to be U+FFFD. (Not saying it's a good strategy, just a possible strategy.) In a single-threaded world, this is fine. Would it be fine with threads? See WebAssembly/threads#189.

@conrad-watt
Copy link
Contributor

conrad-watt commented Jul 13, 2022

IIUC, the complication here in comparison to memory.fill would be the potential for a racing thread to observe the unsanitised surrogate before it's overwritten. We could write the specification for string.encode_lossy_utf8 so that this additional behaviour is permitted without too much trouble if this is a desirable implementation to support (i.e. a racing thread could see arbitrary interleavings of the old data, the unsanitised new data, and the sanitised new data).

@jakobkummerow
Copy link
Collaborator

if this is a desirable implementation to support

It's not a big issue either way, but the single-memcpy-plus-fixups implementation is a nice simplification compared to the alternative, so yeah, it would be nice (but not crucial) to support it. You can see the difference here (lines 1274 and following).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants