Why is the use of alloca() not considered good pra

Question

alloca() allocates memory from Stack rather than heap which is case in malloc(). So, when I return from the routine the memory is freed. So, actually this solves my problem of freeing up of dynamically allocated memory. Freeing of memory allocated through malloc() is a major headache and if somehow missed leads to all sorts memory problems.

Why is the use of alloca() discouraged in spite of the above features?

Answer 1

Old question but nobody mentioned that it should be replaced by variable length arrays.

char arr[size];

instead of

char *arr=alloca(size);

It's in the standard C99 and existed as compiler extension in many compilers.

Answer 2

alloca () is nice and efficient... but it is also deeply broken.

• broken scope behavior (function scope instead of block scope)
• use inconsistant with malloc (alloca()-ted pointer shouldn't be freed, henceforth you have to track where you pointers are coming from to free() only those you got with malloc())
• bad behavior when you also use inlining (scope sometimes goes to the caller function depending if callee is inlined or not).
• no stack boundary check
• undefined behavior in case of failure (does not return NULL like malloc... and what does failure means as it does not check stack boundaries anyway...)
• not ansi standard

In most cases you can replace it using local variables and majorant size. If it's used for large objects, putting them on the heap is usually a safer idea.

If you really need it C you can use VLA (no vla in C++, too bad). They are much better than alloca() regarding scope behavior and consistency. As I see it VLA are a kind of alloca() made right.

Of course a local structure or array using a majorant of the needed space is still better, and if you don't have such majorant heap allocation using plain malloc() is probably sane. I see no sane use case where you really really need either alloca() or VLA.

Answer 3

The answer is right there in the man page (at least on Linux):

RETURN VALUE The alloca() function returns a pointer to the beginning of the allocated space. If the allocation causes stack overflow, program behaviour is undefined.

Which isn't to say it should never be used. One of the OSS projects I work on uses it extensively, and as long as you're not abusing it (alloca'ing huge values), it's fine. Once you go past the "few hundred bytes" mark, it's time to use malloc and friends, instead. You may still get allocation failures, but at least you'll have some indication of the failure instead of just blowing out the stack.

Answer 4

A place where alloca() is especially dangerous than malloc() is the kernel - kernel of a typical operating system has a fixed sized stack space hard-coded into one of its header; it is not as flexible as the stack of an application. Making a call to alloca() with an unwarranted size may cause the kernel to crash. Certain compilers warn usage of alloca() (and even VLAs for that matter) under certain options that ought to be turned on while compiling a kernel code - here, it is better to allocate memory in the heap that is not fixed by a hard-coded limit.

Answer 5

Not very pretty, but if performance really matter, you could preallocate some space on the stack.

If you already now the max size of the memory block your need and you want to keep overflow checks, you could do something like :

void f()
{
    char array_on_stack[ MAX_BYTES_TO_ALLOCATE ];
    SomeType *p = (SomeType *)array;

    (...)
}

Answer 6

The alloca function is great and and all the naysayers are simply spreading FUD.

void foo()
{
    int x = 50000; 
    char array[x];
    char *parray = (char *)alloca(x);
}

Array and parray are EXACTLY the same with EXACTLY the same risks. Saying one is better than another is a syntactic choice, not a technical one.

As for choosing stack variables vs heap variables, there are a LOT of advantages to long running programs using stack over heap for variables with in-scope lifetimes. You avoid heap fragmentation and you can avoid growing your process space with unused (unusable) heap space. You don't need to clean it up. You can control the stack allocation on the process.

Why is this bad?