Fix byte order for big-endian platforms

[magic-akari]

Note

WebAssembly memory is always in little-endian format, regardless of the platform it's run on. Therefore, for portability, you should read and write multi-byte values in JavaScript using DataView.

https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Memory

Related issues:

• @swc/wasm-typescript is failing on some architectures swc-project/swc#9259
• module: add --experimental-strip-types nodejs/node#53725 (comment)

[magic-akari]

Could you review this pull request? @daxpedda

[daxpedda]

I'm a bit confused why you chose not to re-use expose_*_memory().
The only place it still seems to be used is for importing arrays, which you actually haven't covered here.

I will have more time tomorrow to look into this properly.

Could you review this pull request? @daxpedda

I apologize for the delay, my backlog from my vacation was quite big and I'm just getting to it.

[magic-akari]

I'm a bit confused why you chose not to re-use expose_*_memory(). The only place it still seems to be used is for importing arrays, which you actually haven't covered here.

Could you please specify which part you're referring to? Marking it on the relevant code would be helpful.

[daxpedda]

All these functions could be adapted:

wasm-bindgen/crates/cli-support/src/js/mod.rs

Lines 1782 to 1812 in 7f3c21b

	fn expose_int16_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("Int16", memory)
	}
	fn expose_uint16_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("Uint16", memory)
	}
	fn expose_int32_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("Int32", memory)
	}
	fn expose_uint32_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("Uint32", memory)
	}
	fn expose_int64_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("BigInt64", memory)
	}
	fn expose_uint64_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("BigUint64", memory)
	}
	fn expose_f32_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("Float32", memory)
	}
	fn expose_f64_memory(&mut self, memory: MemoryId) -> MemView {
	self.memview("Float64", memory)
	}

The corresponding memview() as well.
What this PR does is only switch pointer handling and vector exports to the DataView API, is there any reason not to just switch everything? AFAICS vector importing is missing.
It would require much less code changes and the logic could be simplified.

[daxpedda]

My earlier assumptions were wrong, when getting arrays out of Wasm to JS land, we can't actually use DataView, this is a responsibility the user will have to take when extracting data from DataView.