Okay, so I googled it and I read around a bit. Also, there was condescension somewhere? Lol wut?
First, I read the man page on alloca. They do claim that it is both machine- and compiler-dependent and that they discourage its use but do highlight that it can improve the efficiency of certain applications. And that agrees well with the theory. Granted, new() may be near just as fast but I want to avoid it because I want some large number of threads running the same code. Stack allocations vs. heap allocations in this case have the potential to be costly (if using new()) when running on some 16 core processor because now that's 16 searches through the pool instead of just throwing something on top of the stack 16 times.
It's one more thing that can make code faster and there's a Windows version and the Windows version even got an upgrade to _malloca. _malloca
There's even a _freea to go with _malloca which I think is awesome.
But phantom, the man pages also highlight what you said as well. It can't be used as arguments (which freaked me out, I've never once thought of using a function's return as an argument) and it doesn't return a failure so you're free to go beyond the stack. But if your OS can't handle a SIGSEGV signal, then please, stop using a OS from 1984. Sorry, that last line isn't meant to attack anyone, I just think it's a funny joke because I think kernels are strong nowadays (that's like a kernel-level thing, right?). I've crashed tons of code (trust me) and so far it's all been fine. If your code crashes, hopefully your computer won't run havoc and delete your system. What is this, 1995?
And if not alloca, how am I supposed to get variable length arrays on the stack in C++ if ISO C++ forbids it? I tried googling it and the answer was to use new() which made me run away in fear. C gets it, so why not us?