trailing whitespace removed
fixed a bug - make the code actually run

Okay, this is tough. By _first_ allocating big_array we made the stack frame huge. Good. But we _next_ called f(), which made it overwrite the next stack frame. All good, but that means that if GCC decided to allocate anything _after_ big_array it will actually touch the stack frame of next coroutine (as it will be _after_ big_array and therefore by definition it will go to a stack frame of next call to grow_stack).

This may not be obvious, but GCC does decide sometimes to push items after _big_array_. For example this is a snippet that calls f().

   0x08048894 <+389>:   mov    %eax,(%esp)
=> 0x08048897 <+392>:   mov    -0x10010(%ebp),%eax
   0x0804889d <+398>:   call   *%eax

Please see that before getting pointer to f() from stack, we do save EAX to stack. Actually, this will cross the stack frames (as it's _after_ bigarray) and go to the stack frame of next coroutine. Whoops.

So basically the whole idea is broken.

Instead what we should do: allocate bigarray _only_ when we do grow the stack. Otherwise - keep the stack frame small, so even if gcc decides to write something after our current stack frame it goes to the stack space reserved by us. We can dynamically allocate the space on the stack by using `alloca` call. Assuming GCC won't reorder stuff heavily it should work. So now we do:

 - grow the stack frame using alloca to huge only when we allocate space for coroutines
 - when we're inside a coroutine, the stack frame is thought to be small (like _before_ calling alloca) and therefore by definition if we grow the stack it will hit the memory that we did reserve using alloca.

This should be much more robust :)
Update: Actually gcc will optimize out alloca with higher -O setting. Make sure it desn't happen by using an asm trick.
Update makefile: Don't use -O by default, make sure FORTIFY_SOURCE is not enabled - otherwise our code will (properly) crash on context switch on linux