# Is accessing WebAssembly memory using TypedArrays incorrect on Big Endian systems? **URL:** \ **Category:** I have questions\ **Created:** [April 15, 2023, 5:58pm UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696 "2023-04-15T17:58:59Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![majaha](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/majaha/32/1717_2.png) [@majaha](https://es.discourse.group/u/majaha)\ **Post date:** [April 15, 2023, 5:58pm UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696/1 "2023-04-15T17:58:59Z")
Hey all. I think I've found an endianness compatibility issue with the way people are usually accessing WebAssembly memory, which I've described here: [https://github.com/mdn/content/issues/25569](https://github.com/mdn/content/issues/25569). The basic idea is that WebAssembly linear memory is always little-endian. But people are accessing it with `new Uint32Array` and the like, which interpret multi-byte accesses using the _platform_ endianness, which will break on big-endian platforms. I was hoping some people experienced with the ECMAScript and Wasm specs could weigh in on whether this is a correct reading. Am I along the right lines here? ---
**Author:** ![mhofman](https://avatars.discourse-cdn.com/v4/letter/m/f14d63/32.png) [@mhofman](https://es.discourse.group/u/mhofman)\ **Post date:** [April 15, 2023, 11:34pm UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696/2 "2023-04-15T23:34:24Z")
TypedArray use the native endianness for performance, whereas DataView will default to big endian. As far as I know this is fairly [well documented](https://hacks.mozilla.org/2017/01/typedarray-or-dataview-understanding-byte-order/). TypedArray actually let you discover a lot of other implementation specific quirks, like how there are in fact multiple NaN values. The fact that WebAssembly uses little endian can indeed create issues, but since neither spec can change that at this point, the best that could be done is to make the compatibility issue clear in developer resources for those programs that share memory between JS and WebAssembly. I actually doubt that JS programs reading WebAssembly written memory (or vice versa) would rely on TypedArray since I'd assume the shared memory would usually contain data of various types. ---
**Author:** ![Josh-Cena](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/josh-cena/32/1408_2.png) [@Josh-Cena](https://es.discourse.group/u/Josh-Cena)\ **Post date:** [April 15, 2023, 11:57pm UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696/3 "2023-04-15T23:57:23Z")
So the impression is right that developers should be discouraged from using anything other than `{Ui,I}nt8Array` to view WASM memory? Note that using `Uint8Array` to view memory is [listed in the resizable arraybuffer usage examples](https://github.com/tc39/proposal-resizablearraybuffer#sync-up-capability-with-webassembly-memorygrow). Currently, [MDN has examples](https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Memory#creating_a_new_memory_object) that create `Uint32Array`s from `memory.buffer`, so if this is nonportable, we would need to update our content. ---
**Author:** ![mhofman](https://avatars.discourse-cdn.com/v4/letter/m/f14d63/32.png) [@mhofman](https://es.discourse.group/u/mhofman)\ **Post date:** [April 16, 2023, 1:14am UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696/4 "2023-04-16T01:14:44Z")
UInt8Array is fine in itself. The problem is for any multi-byte data. So the portability issue is regarding any multi-byte TypedArray. I assume the MDN examples should be updated, yes. ---
**Author:** ![Josh-Cena](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/josh-cena/32/1408_2.png) [@Josh-Cena](https://es.discourse.group/u/Josh-Cena)\ **Post date:** [April 16, 2023, 2:05am UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696/5 "2023-04-16T02:05:43Z")
Thanks for confirming. The MDN content will be updated. ---
**Author:** ![mhofman](https://avatars.discourse-cdn.com/v4/letter/m/f14d63/32.png) [@mhofman](https://es.discourse.group/u/mhofman)\ **Post date:** [April 16, 2023, 3:56am UTC](https://es.discourse.group/t/is-accessing-webassembly-memory-using-typedarrays-incorrect-on-big-endian-systems/1696/6 "2023-04-16T03:56:32Z")
I'm wondering if an option on the constructor of TypedArrays would make sense to force a certain endianness interpretation of the bytes. That would have to go through the proposal process. I am still doubtful however that many use cases would use multi-byte TypedArray to access Wasm memory.