Daniel Lehmann

Good point, this is definitely useful. Out of interest: What would be your application? (E.g., something along the lines of fault injection by randomly changing instruction results?) Unfortunately, I think...

> If we happen to know some condition needs to be set, but don't quite understand why it needs to be set, having the ability to modify the state would...

Can you elaborate a bit how Wasm3 (which is an interpreter for Wasm, right?) is useful for Wasabi?

`wasm-interp` is not used right now in Wasabi (Wasabi instruments purely statically, which is why I'm asking.)

The instrumentation is static, the analysis happens dynamically (but in the browser or Node.JS, since we assume a JavaScript host environment, which was the only type of host at the...

Alright, for more comments/ideas on WASI support in Wasabi, let's stick to #23.

Interesting idea! So just to clarify the overall goal: You would like Wasabi to work with host environments that are *not* using JavaScript (browsers or Node.JS), but instead WASI (an...

With the technicalities sketched, let's zoom out a little. 1. Comment: this will be a larger implementation effort (compiling analyses e.g. from Rust to Wasm+WASI, testing that, how to merge...

Hi rxEckT, Ah nice, that looks very good indeed :-) If you are fine with the MIT license of the project, I will use this as a basis for implementing...

Sure, that would work for me. I was more wondering what the reason for the separate `Encode` trait is, and whether it could be replaced by the standard `io::Write`.