It's a matter of the ABI, and most importantly the calling conventions. Plus, depending on the architecture, you'll not be able to use some of the builtin push/

It's a matter of the ABI, and most importantly the calling conventions. Plus, depending on the architecture, you'll not be able to use some of the builtin push/pop/call/return-like instructions anymore. This can be a minor caveat or a major performance penalty, depending on your program and target architecture. And I'm not even talking about compiler-builtins or libc stuff that will wreak havoc unless you rewrite all of that for your new ABI. Also: The program still crashes at "random" spots instead of behaving unpredictable. But for that you could add some assembly at the beginning of each function, asserting that the sp is in the pre-defined stack range. If your hardware supports it, you could also mark the "overflow area" behind the stack as read-only and let it crash that way. Due to a past job I'm biased to static program analysis for this task, something the post author completly neglects (doesn't know about?). At least if sound boundaries matter (e.g. safety critical stuff).