Why not a fill()-type API?

[xfbs]

Hey guys! Awesome work here. I'm working on passgen in my free time and I'm trying to make this work well within WASM/WASI. For that, I obviously need access to good random data. Right now, I'm using Linux's getrandom() and arc4_random() on macOS. So much for context.

In my code, I have a ring buffer of random data that I use up and then replenish by filling it with random data, overwriting what was in it previously. Hence my question: why not a fill()-style API?

let bytes: Vec<u8> = get_random_bytes(len);

vs

let mut bytes: Vec<u8> = Vec::new();
fill_random_bytes(&mut bytes[..]);

I might be missing something here — kind of new to this WASM/WASI thing. Please excuse me if this does not make sense.

The advantage of this would obviously be that I don't need to create a new buffer of random data every time, but I can just have one buffer around. The other advantage is that by continuously overwriting the random data, you can't accidentally leak it, like you could with new allocations. This might not be an issue for WebAssembly, however.

Cheers,
Patrick

[sunfishcode]

WASI is moving to the Wit IDL and the component-model type system, and at the IDL level, the component model uses pass-by-value semantics for all values. It doesn't have a mutable reference type at the IDL level. This ensures that the interfaces are usable from all languages, including languages that use GC instead of linear memory, and it avoids lifetime and thread synchronization questions that would arise with a mutable buffer, especially in languages that don't have a borrow checker.

That said, are a few ways that we could generate more clever bindings at the Rust level that would allow users to pass in a buffer and have random-bytes fill in the buffer without needing to allocate a new buffer each time. That's a worthwhile optimization that I look forward to seeing us implement. But the great thing about designing APIs with the Wit IDL is that this can be done as an internal optimization in the bindings tools, so we don't need to design interfaces up front to enable this; we can enable this when we're ready to start optimizing these kinds of things.

[xfbs]

Gotcha! That makes sense. I figured I was missing something. I suppose you can close this issue then, since that answers my question. I also don't think that is is terribly important to optimize this API for speed, the bottleneck is usually the kernel generating the random data.

One side question: what is a good way to get involved in this effort? I really like where WebAssembly is going, and would not mind getting involved.

[sunfishcode]

WebAssembly/component-model#175 is an issue tracking this optimization in the bindings.

It'd be great to have more people involved. We don't have many resources yet for newcomers, though we're starting to work on that. Right now, https://github.com/bytecodealliance/preview2-prototyping is a place where I and others are working on prototyping the new APIs, which may be interesting to follow.

[sunfishcode]

Closing, as per the discussion above, the way wit works, this is more a question for the bindings than for WASI itself.