I've wanted to do this for years and finally got around to doing it (after like 20 chatGPT prompts of non-working implementations :sweat_smile:) - this is a proof of concept for detecting stack overflows in any C program:
https://gist.github.com/rtfeldman/08649614547bdb29bdad35cd73e54104
what's cool about this is that theoretically any Roc platform can use it to give nice error messages for stack overflows, just like a language with an interpreter can do (but without the overhead of an interpreter, of course)
Rust version, ported by chatGPT with mistakes manually fixed: https://gist.github.com/rtfeldman/00d5777c44bafeaf70b5589b5984e500
for context, this is something that has to happen in the platform (specifically the host) because doing it requires setting up a signal handler, and if Roc did it automatically for every entrypoint, then not only would it be wasteful (setting up the same handler multiple times) but also it would risk stomping over an existing handler that the platform wanted to set up for other reasons - so the platform needs to be in control of (and the only implementer of) a handler to detect and gracefully report stack overflows
I wonder if you could just use standard stack canaries (from GCC or clang) or the zig stack probe as well. Don't really know the underlying details of those.
one of the answers GPT-4 gave me at some point was supposedly a stack canary, and it didn't work :sweat_smile:
but maybe there's some way to get that to work
but yeah I don't know the details of any of those either
if someone is on Linux and/or Windows and could try running :point_up: to see if it works, that would be helpful!
basically there are some commented-out tests at the end of main
which exercise various different segfaults; they should all get an explicit error message printed, and it should only say it was a stack overflow if it actually was a stack overflow
I would guess that roc would need to add a pass to LLVM to keep using stack canaries and the host would have to set it as well. Or something of that nature
there's also https://github.com/roc-lang/roc/issues/806 to consider in the future
Last updated: Jul 05 2025 at 12:14 UTC