Steffen Nurpmeso dixit: >a different, even older message: use a recursion counter, how >wacky that may be.
Nah. It’s either too high (with the obvious effect) or, like PHP’s, way too low (1000 just doesn’t cut it in may legitimate cases). And even a too-low one can still segfault if the user plays with ulimit -s. >It's just that i am with the one that got no answer in that it >didn't feel right. Just forget about it. Yeah, sorry about it. enh dixit: >VMs have to deal with the more general case of this problem so they >can throw whatever "stack overflow" exception their language defines. Hm. Not that I ever implemented even a toy VM worth note, but I’d most definitely not use the host’s stack for the VM stack, rather allocate the latter on the host heap. >work out where the main thread's stack should end from /proc/maps and Ah, but that assumes there i̲s̲ a /proc/maps in the first place. >surprisingly brittle, non-portable, and hard to get right though, so >i'm not recommending you bother. Right. I w̲a̲s̲ wondering a bit… about a stack underflow SIGSEGV being the only one I can’t really catch… but then I remembered sigaltstack(2). Still, once I caught the SIGSEGV, what is there I can do… I guess in this case I could (after maybe setting a flag) siglongjmp to the next “up” error handler… but for that, I’d have to know that the cause of the SIGSEGV was actually a stack underflow. Or, on some platforms, stack over(!)flow. I’ve got to admit that this part of Unix is something I’m still not familiar enough with. bye, //mirabilos -- <igli> exceptions: a truly awful implementation of quite a nice idea. <igli> just about the worst way you could do something like that, afaic. <igli> it's like anti-design. <mirabilos> that too… may I quote you on that? <igli> sure, tho i doubt anyone will listen ;)
