Programming

Any time you want a local buffer without predefining its size, for one thing. achenle also had a good point about it being threadsafe hence much faster than trying to synchronize malloc for multithreaded things.

It's interesting how each platform discourages the use of alloca because of how it might behave on some other unmentionable platform without confessing to being guilty themselves. This could stand some testing, I think. alloca's almost as old as UNIX itself, circa AT&T V32 1979, making me wonder how historical this complaint is and how relevant it actually remains.

---------- Post updated at 04:24 PM ---------- Previous update was at 03:57 PM ----------

I wonder if this fails on any of your machines. I'm trying to smash stack memory in the manner described by passing and assigning to large stack variables as well as deep recursion.

Code:

#include <stdio.h>
#include <string.h>
#include <alloca.h>

struct hulk {   char buf[1024]; };

struct hulk smash(struct hulk h, int n)
{
        memset(&h, 0xff, sizeof(h));
        if(n > 0) h=smash(h, n-1);
        return(h);
}

int main(void)
{
        int n=0;
        struct hulk h;
        char *mem=alloca(sizeof(h));

        memset(mem, 0x7f, sizeof(h));
        memset(&h, 0x00, sizeof(h));
        h=smash(h, 5);

        for(n=0; n<sizeof(h); n++)
        {
                if(mem[n] != 0x7f)
                {
                        fprintf(stderr, "hulk smashed\n");
                        return(1);
                }
        }

        return(0);
}

So far OSX on PPC, and Linux on x86-32, x86-64, and embedded-linux MIPS(with ulibc) do not accidentally overwrite memory returned by alloca.

Thank You all for your replies.

alloca() is not part of any standard such as ISO C or POSIX for a very good reason. It is not fully portable across computing architectures and programming models. For example, how do you implement it on architectures which do not have a stack?
Since alloca() is not standardized you cannot rely on alloca() being threadsafe across implementations. It may or may not be.

What stack-free architectures? I can't find any except the PIC16, an embedded processor line with more I/O ports than RAM. And even then they were forced to emulate a stack to write a C compiler for it. I would have expected PPC or MIPS to be the ones to fail on this, being more RISC-like architectures that play funny games with the stack, but they work fine. It's a very low-level call that works by modifying the stack frame -- a thread-local property. It would take an extremely strange implementation of it to not be threadsafe.

It is worth testing, though. I'll see what I can come up with.

A major problem with using alloca() is that it does not fail gracefully when it fails. Usually a SIGSEGV or SIGBUS occurs which is difficult to debug because the SIGSEGV or SIGBUS may not necessarily occur anywhere close to the alloca() call.

Such a crash may be reproducible in one specific environment but not in another. This is usually the result of different stacksizes. An application's default stacksize depends on the user environment and may have been modified via ulimit or some other mechanism. Furthermore, in a threaded application a thread stacksize may differ from the process stacksize and from another thread's stacksize.

This is just standard memory behavior. C's inability to warn you of impending stack faults doesn't stop people from using recursion and local variables, fortunately. If alloca is actually broken on some platform, though, that would be very good to know...

I get that but my question was more about how are you going to use a dynamically allocated stack buffer.
It's just as easy to do with malloc.
I would be leary of using a C lib function that is non-portable and strongly discouraged by the vendors who make it as it goes against the very purpose for which C was created i.e. portability. Otherwise we would all be coding in assembly which would be very cumbersome given the number of different mpus in the market today.
I have a hard copy of the UNIX Programmer's Manual (7th ed. Vol. 1 Jan. 1979) and alloca is nowhere in it.