Hmm, interesting point. I didn't even know of the red zone or how this could cause trouble.

As far as I understood the problem here are signal handlers which could start executing when our stack pointer points to the wrong location and overwrite some of our data, right?

There's no red-zone in ARM but I think it doesn't cause problems: The fact that we store the stack pointer earlier doesn't matter. The signal handler only cares about the value in the SP register and this value is correct until we load the saved value into it. The only point in time where the stack register is 'wrong' is between loading it and adding/subtracting the offset. However, on ARM we're lucky and this is one instruction and should be atomic:
```asm
sub sp, r1, #72 ;before:old, valid SP after: new, valid SP
```
So we actually never have a wrong stack pointer. I think most other architectures should also be fine if the new stack pointer is in a non-sp register first (it should be in the parameter register anyway), then adjusted and then only the final value copied into sp.

BTW: If this GCC patch http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00231.html has been applied it should be possible to find the red zone sizes in the GCC sources.