i noticed a typo:

"but it I_ being supplemented"

tbh it is so on the nose that I wonder if OP is intentionally restating the Chinese Room Argument? (like maybe OP wants the CRA without the language aspect, without Chinese)

I loved Bard's Tale III too! One of the first games I bought, 100% worth the cost.

The music, the puns ("eye gotcha"), the scope, just a great adventure...

Very sad about Rebecca.

Ha, yes ...

Also 64K

Oh, and as one random data point, emcc reduced the stack size by a lot a few years back, making this a lot riskier. We did get an uptick in reports, but quite small

(again, not conclusive, jut saying where my intuition here comes from)

Definitely, yeah, most users never report. Most open source users never interact at all with upstream...

Still, while we can't tell the absolute numbers, I hope (but could be wrong!) that the reports we do get, on issue trackers and elsewhere, hint at the relative importance of problems

Yeah, good points. I wish this was simpler. Emcc and Rust etc can do stuff like this in their compiler driver logic, but wasi-sdk alone needs another solution...

I think if stack overflow problems were a major issue, those things would have been a higher priority.

But also, wasi-sdk is mostly used off the web, where code size matters less, so again I agree with you on the new default, and maybe most wasi-sdk users just don't need anything else, yeah

True that while the Binaryen pass can run on wasi-sdk output, it lacks docs, yeah.

But porting sanitizers would not be too hard, I think. Can base off of Emscripten's, and replace/remove the stack trace logic.

I didn't mean to equate those, no.

(But I do sort of collect data for both, in that I follow both issue trackers and listen to users of both elsewhere as well.)

Given those tools, my sense from user reports is that weird stack-related crashes are not a significant problem

And there are users that do care about every percent of binary size on the web

(though, again, I agree with you on the right defaults here)

Fair enough, though I'd say there are good mitigations for those crashes:

1. Stack overflow checks can be added in production: github.com/WebAssembly/...

2. During development there are also sanitizers: emscripten.org/docs/debuggi...

This might be the right default, but it does have a size downside?

If you don't compress LEBs then I guess not, but if you do, it can be significant: some codebases have lots and lots of references to global data, and making those e.g. 3 bytes instead of 2 can add up.

Sounds like that was "fun", heh...

I did get lucky here... after getting those huge files, validation checks pointed to the breaking one, and then wasm-reduce quickly found a small testcase. The fix was simple:

github.com/WebAssembly/...

good thing storage is measured in TB these days