+---------- On Feb 11, Jerry Asher said: > It might not solve the problem of one thread still corrupting > another thread's memory or stack, but assuming a page was larger than > several stack frames, it would certainly catch most typical stack > overflows. Wouldn't it?
Yes, it would catch most overflows. But not all. I suspect that guard pages are disabled by default, at least on Linux, and that the gcc "-fstack-check" flag enables them. Try "info libc" and search for "guardsize". > But again, maybe I'm missing something here. When I was writing > compilers for some small functional languages, I knew, or rather the > compiler knew at every subroutine push, just how large the new stack > frame had to be. It would seem to be pretty easy math, and not too > harsh of an efficiency hit to have the compiler/interpreter check > available stack size at each function entry. Note that each time you create a stack from (or otherwise dynamically extend the stack), you need to compare the SP to a thread-specific limit, which means using TLS. I'm not sure how long Linux (for example) has supported TLS, and I'm pretty sure that its support has changed over time, so checking SP is not necessarily trivial. I agree that SP checking would be useful, at least as an option.
