just don't do this.

  int a(){
    void* mem = allocal(some_number);
    b();
  }

  int b(){
    a();
  }

if a() is a leaf (or can be trivially inlined) it's fine!

on the other hand, if a() calls something else, that's complicated, it's way way harder to figure out why you're crashing. I think you'll segfault as a() eventually overwrites malloc'ed memory. but different systems are going to have different characteristics.

It's not that you can't, you just have to be real damn smart and make sure no one ever messes with your code.

or you can just make sure it's a leaf. much easier rule, much easier to explain.

Your example behaves the same with or without alloca.

It will run until it runs out of stack. Or it might just run forever because the compiler optimized it as an infinite loop.

In any case, same behavior.

True. How would you modify it to get the point across?

Or am I crazy, and there is no point to being careful with alloca?

Maybe if alloca is used with a runtime value uncapped, a user could then trigger a stack overflow with too big of an allocation. This is the same problem when allocating on the heap, with the difference that the heap is a few order of magnitude larger.

That is really the only difference between `in foo[...N] = ...N` and alloca(n). alloca works with a value computed at runtime. And this value could be from an input.