A GCC -fstack-protector vulnerability on arm64

For most programs, having a very rare, badly performing worst case is better than having an always occurring worst case that isn't quite as bad, but is still a bit worse than the common case in the "rarely very bad" scenario.

See: usage of quicksort O(n^2) vs mergesort O(nlgn).

Since quicksort is *usually* faster, it often is the better choice, despite having a much, much worse worst case.

In fact, if one always just allocated the worst case statically, there'd actually be no point for heap memory whatsoever - just allocate for the worst case, for anything.

>There is no benefit in converting a program that unconditionally overruns the stack to one that conditionally overruns the stack.

Yes, there is: if the condition is very rare, of course it's far far better to have a program that only (rarely) conditionally overruns the stack, instead of one that always overruns it. The only benefit of having a program that always runs out of memory is if you're selling memory (or trying to convince someone who needs 99.9999% uptime that the worst case will crash on the given hardware, i.e. as a test program)

In fact, the space of programs where it's not preferred to rarely crash instead of always crash is rather small indeed, I would imagine.