For emscripten builds, currently your static data comes at the beginning of WebAssembly's linear memory, followed by the stack and then dynamic data.
There's some discussion of changing the default to move the stack to the beginning, so overflows (growing down) wrap past 0 into out-of-range memory accesses which will trap with a visible error -- instead of silently overwriting your static data which it does now. ;)
(There is a 'cookie' value at the stack boundary which is intermittently checked if you use the SDL/GL/etc rendering loop but it doesn't trigger on library workloads like I'm using.)
Interestingly, since a variable-length encoding is used for integers in WebAssembly binaries, putting static data at the beginning can have a small size advantage for your binary... but I think the debugging and safety advantage will outweigh it as default. :)
@brion yes, let's build something that eliminates a whole class of security vulnerabilities instead of repeating the mistakes of the past.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!