3 ms·
> WASM is not designed to work around the shortcomings of C. Memory access protection on modern systems is not about C segfaults. But if WASM embraces MS DOS e
by josefx 4y ago
> WASM is not designed to work around the shortcomings of C.
Memory access protection on modern systems is not about C segfaults. But if WASM embraces MS DOS era memory access management then then that is certainly a choice, might even still be an improvement over plain JavaScript. Does it at least have near and far pointers?
- s-macke 4y agoWell, the WASM binary format uses variable-length integer encoding. You can see this as an enhanced version of near and far pointers.
- int_19h 4y agoIt's not segmented, so no... or rather, not yet. The wasm spec already accommodates to some extent the notion of multiple "memories" (i.e. distinct flat heaps), although it only allows for one in practice: https://webassembly.github.io/spec/core/syntax/modules.html#memories https://webassembly.github.io/spec/core/syntax/modules.html#... And there's an active proposal to allow for multiple memories: https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md https://github.com/WebAssembly/multi-memory/blob/main/propos... In an environment like that, you'd need full-fledged pointers to carry both the memory index and the offset; and then you might want a non-fat "pointer to same memory" alternative for perf. Might as well call them far and near.