> Not everywhere in the tree checks the return value from > alloca (right now it will abort instead of returning > NULL, but that, hopefully, is soon to change; hooray > for laying groundwork). This takes us a little bit > closer to sanity. You should actually look at how alloca is implimented, and I don't mean the .c version in libc. alloca just reduces the stack pointer, and thus, does not return NULL for failure. The manual page specifically avoids talking about NULL for failure. alloca() does not have a defined failure return. And no, it does not abort() either. Instead, alloca silently does "the wrong thing". And that cannot be easily fixed.

> Agreed, the default alloca behaviour is hard to fix (and I don't pretend > to even begin to know how), but the tests for NULL seem harmless, if > superfluous, in these cases. The test for NULL acts as if there is a safety scaffold, when the reality is that there isn't safety mechanism at all. The safe way to use alloca is to know up front if it is safe. If you don't know that it is safe, you don't use it. Checking afterwards doesn't work, so there's no point in having such checking code.

> > The safe way to use alloca is to know up front if it is safe. If you > > don't know that it is safe, you don't use it. > > How do you know when it's safe? When there is enough stack. > Wouldn't you have to know how much > room you have left on the stack and that it is less than the amount > you want to alloca()? Exactly. > I suppose one could check that *prior* to the > alloca() (code not portable?), No, one can't check. > but are there other assumptions a > programmer can make when considering use of alloca() to know if it > would be safe? One can know "I am not deep in my call trace" and "the allocation is small". Then it is safe to use. This is not much different than knowing when it is safe to walk with your eyes closed. It's a dangerous API. If you don't know when to use it, just plain don't use it.