jakobkummerow

Sorry that it took a while to get to this. Can you confirm that https://github.com/GoogleChromeLabs/jsbi/pull/103 fixes the issue? I don't have a big endian machine to test it on myself.

Implementing Wasm i32 arrays as JS Int32Arrays under the hood would be possible, I think, but it would be quite a bit slower than our (V8's) current strategy of implementing...

> a way to compare funcrefs for equality I agree that this would be useful to have. Implementation perspective: if we expect that repeated creations of funcrefs for the same...

Thanks for confirming. I'll fix V8's implementation accordingly. I still think it would be good to clarify this in the spec text and/or tests.

As long as you're building everything from source and you're using C++, I think this could fairly easily be done by adding namespaces: include several copies of `wasm.hh`, wrap the...

My vote is to drop `vec::make_data` and `vec::free_data` entirely. If an implementation of the library wants to do accounting for debugging/development/investigation purposes, it can find some way to hack that...

> linking the lib against an app that is not (yet?) LSan-ready I don't see the use case for that? When debugging the library for memory leaks, you can (and...

My reasons for preferring to drop `make_data` and `free_data` are: - I think it's nice when library and client can be compiled independently (at different times, on different machines, with...

I don't think `__uint128_t` is a viable option: compilers for 32-bit platforms (x86 and arm) don't support it, and MSVC even for 64-bit doesn't support it either. In the interest...

Nope, not a V8 bug; it's a footgun in the API design. `instance.get()->exports()` gives you an `ownvec`, so right after you do `[0]->` on it the `ownvec`, being a temporary...