Wasm Tables and Functions

Unlike C function pointers on native hardware, WebAssembly deliberately forbids storing a raw callable function reference as data inside linear memory — this is a security boundary, preventing a corrupted or attacker-controlled buffer from ever being reinterpreted as executable code. Instead, WebAssembly introduces a separate address space specifically for callable references: WebAssembly.Table, a resizable, typed array whose elements are funcref (or, with the reference-types/GC proposals, externref) values, indexed by ordinary integers just like an array but stored completely outside the linear-memory byte space.

A direct call instruction invokes a statically-known function by its index in the module — the equivalent of calling a named function directly in source code. call_indirect instead takes a runtime i32 index into a Table, looks up the funcref stored at that slot, verifies its type signature matches what's expected at the call site (throwing a trap if it doesn't), and only then invokes it — this is precisely how compiled C/C++ function pointers, C++ virtual method dispatch (vtables), and language-level closures/callbacks work once lowered to WebAssembly.

WebAssembly.Table is constructible from JavaScript exactly like Memory — new WebAssembly.Table({ element: 'funcref', initial: 4, maximum: 16 }) — and grows via table.grow(delta, fillValue). Crucially, table.get(index) returns a function reference usable directly as a JavaScript callable (calling it just invokes the underlying Wasm function), and table.set(index, fn) lets JavaScript install a JS function into a slot a Wasm module will later call indirectly — this is the mechanism that lets a Wasm module invoke a JavaScript callback through an indirect call rather than an import.