There's another reason: we need to do string stuff and we absolutely can't stall. Malloc always has some chance of stalling due to heap fragmentation. The leaf function requirement is also not necessary. You just have to make sure you don't alloca too much memory given how much is remaining on the stack and roughly how much memory you know subsequent calls will take.

It's not all that much worse than using a huge, static stack allocation. In fact, there are cases where alloca is safer since you can take into account how much stack memory you already have available before incrementing the stack pointer.

With a huge static stack allocation the stack check must be done within a parent function instead of within the same function.

In any case it is up to you to do the stack check. Though alloca can easily be wrapped by a function running the check.

In Rust I would write a check stack function that takes a function/closure as parameters. Within the closure, you are guaranteed to have at least the requested stack space.

The compiler will inline it all nicely, while preserving the semantic of the stack allocation.

Why does it have to be a leaf function?

So the massive stack grab isn't permanent.

Conceptually, if the compiler could just inline all of the child calls, it's fine. But if this call won't return for a long time, or may be called again (even worse). You're setting aside stack that you'll never get back. Which is a memory leak, and your program will crash.

The stack grab is as permanent as any other stack variable. There is nothing special about it. The only difference is that you can decide at runtime how much to add to the current stack frame.

If the memory's lifetime correctly coincides with the function (which is why you might use alloca in the first place), I don't see how this would be a memory leak nor why it would lead to a crash. Maybe on systems which limit stack size...?

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.

That reasoning leads me to conclude the function should be short lived or the memory in use by all child functions, rather than it has to be a leaf function?

yeah. Leaf is a good rule of thumb, but if you need a little helper to do something it's generally fine.

you really do need confidence the little helper can be fully inlined. if the helper is out of your control, and someone greatly expands its responsibility, it can suck.

So, yeah, effectively a leaf.