Your general point stands - wasm's original goal was mainly sandboxing - but

1. Wasm does provide some amount of memory safety even to compiled C code. For example, the call stack is entirely protected. Also, indirect calls are type-checked, etc.

2. Wasm can provide memory safety if you compile to WasmGC. But, you can't really compile C to that, of course...

▲

kragen 6 hours ago | parent [-]

Correct me if I'm wrong, but with LLVM on Wasm, I think casting a function pointer to the wrong type will result in you calling some totally unrelated function of the correct type? That sounds like the opposite of safety to me.

I agree about the call stack, and don't know about GC.

▲

azakai 4 hours ago | parent [-]

That is incorrect about function pointers: The VM does check that you are calling the right function type, and it will trap if the type does not match.

Here it is in the spec:

> The call_indirect instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must have type funcref. Since it may contain functions of heterogeneous type, the callee is dynamically checked against the function type indexed by the instruction’s second immediate, and the call is aborted with a trap if it does not match.

From https://www.w3.org/TR/wasm-core-2/#syntax-instr-control

(Other sandboxing approaches, including related ones like asm.js, do other things, some closer to what you mentioned. But wasm has strict checking here.)

	▲	kragen 3 hours ago \| parent [-]
		Hmm, I wonder if I was confusing emscripten's asm.js approach with its approach to Wasm. Thank you!