The answer is basically "stack probes", yes.

I find very few relevant hits on that on Google (stack probes apparently also are hardware to measure various quantities such as moisture in stacks of materials), and none that explain to me what they are (you can enable them in gcc and Microsoft's compilers, and rust should use them instead of stack overflow checks, but that's about it), but from what I guesstimate, they are runtime instrumentation, not anything that a rust compiler could do to guarantee that a compiled and linked program never overflows the stack.

Can you tell me more about them?

They're runtime checks, but they're inserted by the compiler at compile time. So yeah, if you link in code that wasn't compiled with them, then that code isn't protected.

You're right that a summary seems hard to find; http://www.delorie.com/gnu/docs/gcc/gccint_124.html has some decent stuff in it, but given that it's random GCC docs, the details may not be 100% accurate today, I dunno, I'm on a flight layover right now, so that's all I've got at the moment :)

They're dynamic checks.

Static checks for stack overflows are infeasible.

They are not infeasible, if you are willing to limit what your language can do.

Doing so doesn’t remove all useful programs, as the first Fortran compilers showed (they used a fixed addresses for all variables, be they local or global (that they did not support recursion is not that surprising, given that many CPUs of the time didn’t have a return stack))

That’s why I asked whether Rust supported such a thing. It would be very helpful, for example, if your build system would tell you that that difficult to test error handler would, if called, overflow the stack before you spent time and, possibly, lots of money, on trying to run it.

> That typically would prevent the use of recursion, but that's not too bad

It also prevents the use of indirect calls/virtual functions, because they can hide recursion. That's Bad.