2 ms·

Can you really? If you depend on a SIGSEGV handler, that handler needs stack space unless you set up a separate stack for it, and I am not sure that is portable

• cryptonector 5y ago
  The point is to cause a defined (by the platform) stack exhaustion failure mode before possibly causing undefined behavior by corrupting memory. The C specs do not define any resource exhaustion failure modes. But actual operating systems, ABIs, platforms -- they do. If you are on a system that gives you a SIGSEGV but no way to catch it on an alternate stack -or if you don't catch or ignore it- then your process will crash. This is fine. It's better than memory corruption.
  • ghoward 5y ago
    Can you give me an example of a platform where your program cannot cause memory corruption if you access an array on the stack out of bounds far enough to corrupt actual existing memory on the heap? Because a SIGSEGV is the best case scenario; the other scenarios are not helped at all by platforms.
    • cryptonector 5y ago
      Say you alloca(1GB), and alloca() is naive and gives it to you even though that 1GB spans several other stacks, and now you write somewhere in the middle. If you're lucky you'll hit unmapped space and trigger a segfault. If you're unlucky you'll scribble over another thread's stack or whatever. But if you progressively write into the alloca()ed area in the direction of stack growth then you cannot corrupt other mappings, and you can only segfault if you exceed your stack's maximum size. Of course, there can be platforms with no SIGSEGV or whatever.