it took so much code and one <nasty hack> to get f...

# webassembly

[ephemient]

it took so much code and one nasty hack to get file I/O in my wasmWasi project; the wrapper generated by the Kotlin compiler doesn't make any paths available to the wasm program. any plans to change that?

[Artem Kobzar]

Could you please describe your use case? What do you replace in the wrapper and what you are trying to achieve?
CC: @Ilya Goncharov [JB]

[ephemient]

WASI can only access files within directories from preopened file descriptors, and the current wrapper does not have anything setup for preopens, I want to have access to some files from my wasmWasi program

[Charlie Tapping]

There isn’t really a way of doing this, the kotlin compiler doesn’t know anything about the vm that will run the module. I haven’t dove deep into the code but at a glance you might need to is to create a host function on graal

[ephemient]

1. other language runtimes read the preopens at startup and use those entrypoints for filesystem access
2. kotlin.wasmWasi doesn't support any I/O yet, so fine I'll do it myself… but the script that it produces for the :wasmWasiNodeProductionRun etc. tasks does not allow any additional options for configuring it. wasmtime has --dir= command-line parameter for example

[Charlie Tapping]

Read the preopens from where? I don’t think I have seen a function in the wasi p1 spec that does that. Theres function lets you check if a fd is available (i.e. preopen), fd_prestat_get. From the kotlin compilers perspective all it can do is leverage features available in the wasm bytecode and maybe it could call a known function but I haven’t seen one. Things are a little different in the component model as it introduces handles which essentially replace preopens as standardise part of the spec and something kotlin could target

[ephemient]

I didn't check the spec but at the very least wasmtime and nodejs just use the file descriptors sequentially (0=stdin, 1=stdout, 2=stderr, 3=preopens[0], 4=preopens[1], etc.)

[ephemient]

matches what wasi-libc and rust assume the format will be. (I didn't check go or zig)