Add annotation support for string parameters #507
Conversation
| @WasmExport | ||
| public void randomGet(Memory memory, int ptr, int len) { | ||
| byte[] data = new byte[len]; | ||
| new SecureRandom().nextBytes(data); |
There was a problem hiding this comment.
nitpick: instead of generating random data we can stick with a predefined constant to avoid flakiness and make the test reproducible.
There was a problem hiding this comment.
This code is never actually called -- we only verify the generated module source code. But I'll change this to have a Random instance as a constructor argument, as it's likely that host modules will have instance fields in practice.
Not sure what you mean, can you elaborate? |
electrum
force-pushed
the
wasi-string
branch
from
d9a84dc
to
d9af6c1
Compare
Sure, sorry, I forgot to give context. |
|
Ah, I understand what you mean. I don't think those are an issue for arguments to host functions, since the memory will be already allocated. Returning strings from a host function should be the same problem as passing strings to an export function. We would need to know
|
The
@Bufferannotation assumes aPOINTER_LENGTHlayout, which seems common. If needed, we can add an enum to support aLENGTH_POINTERlayout, with the default being the former.The
@Bufferannotation could also be extended to supportbyte[], additional character sets for strings, etc.While there is lots more that we could do with layouts, this seems like a good step to handle a common case. It makes the logging for WASI significantly more useable, as we now have strings instead of pointers. This would allow us to add automatic logging/tracing support to the binding generator.