10

I've read quite a few places that alloca is obsolete and should not be used and Variable Length Arrays should be used instead.

My question is this: Is alloca completely replaceable by variable length arrays?

In my particular instance I have something that looks like this:

typedef struct { 
  int *value; 
  size_t size; 
  } some_type;

void SomeExternalFunction(some_type);

...

void foo(){
  //What I thought to do
  some_type bar;
  bar.value=alloca(sizeof(int)*10);
  SomeExternalFunction(bar);

  //what should be done without alloca
  some_type fizz;
  int tmp[10];
  fizz.value=tmp;
  SoemExternalFunction(fizz);
}

Am I missing something or is this an actual good use of alloca? Also assume for this example that for some reason I want for the value to be allocated on the stack

Earlz
  • 62,085
  • 98
  • 303
  • 499
  • 4
    That isn't actually a variable-length array... As you've specified a constant length. And... Even if it *were* a variable length, I'm not really seeing what alloca buys you here, other than making the intent of the code slightly more obscure. (Obviously if you're using a compiler that doesn't support variable length arrays, you don't have a choice between the two anyway) – Shog9 Aug 15 '10 at 19:17
  • See also: http://stackoverflow.com/questions/3452434/in-which-cases-is-alloca-useful (would be a duplicate based on the title, but I feel you're really trying to ask something else... can't tell what though) – Shog9 Aug 15 '10 at 19:22

2 Answers2

24

There is an important difference between VLA's and alloca: The memory alloca() returns is valid as long as the current function persists. The lifetime of the memory occupied by a VLA is valid as long as the VLA's identifier remains in scope. You can alloca() memory in a loop for example and use the memory outside the loop, a VLA would be gone because the identifier goes out of scope when the loop terminates. This means, you can do this with alloca() and enough stack space: 

typedef struct node { int data; struct node *next; };
void fun()
{
 struct node *n=0;
 int d;
 /* Now we are building a single-linked list on the stack! */
 while(d=get_something()) {
  struct node *x=alloca(sizeof(*x));
  x->next=n; 
  x->data=d;
  n=x;
 }
 do_something_with(n);
} // and the whole thing is deleted here..

You can't do this with VLAs.

Nordic Mainframe
  • 28,058
  • 10
  • 66
  • 83
  • 1
    FWIW: this would be a great answer to both [In which cases is alloca() useful?](http://stackoverflow.com/questions/3452434/in-which-cases-is-alloca-useful) and [What’s the difference between alloca(n) and char x\[n\]?](http://stackoverflow.com/questions/2614561/whats-the-difference-between-allocan-and-char-xn) – Shog9 Aug 15 '10 at 23:01
  • This is a great answer regarding the difference, but you might also want to note that the behavior of `alloca` is essentially implementation-defined since it's not specified in any (current) standard. – R.. GitHub STOP HELPING ICE Aug 16 '10 at 05:43
  • By the way, there **is** a way to do the same with VLAs: make the function recursive and call `do_something_with(n)` at the deepest level. :-) Actually I had a real-world use for this, which I haven't yet implemented: a lightweight implementation of `/lib/ld.so` which performs dynamic linking on the stack to avoid bringing `malloc` overhead into tiny programs that don't use it. At the end, it would unwind and discard all the dynamic linking data if and only if `libdl` has not been linked; otherwise it would call `_start` from the deepest level of recursion. – R.. GitHub STOP HELPING ICE Aug 16 '10 at 05:45
  • @R: I remember reading somewhere that the *were/are* alloca's out there which deallocate when the current curly brace section is left. So it's probably a good idea to check the manual. – Nordic Mainframe Aug 16 '10 at 05:49
  • 1
    @R: Chicken Scheme uses a similar technique to perform its allocations: The program is compiled into a set of functions which call continuations with tail call exists, which means that all allocation could happen on the stack. The garbage collector would move the live objects to the heap when the stack is full and rewind the stack by performing a "return". – Nordic Mainframe Aug 16 '10 at 05:55
-2

alloca is completely replaceable by malloc and free. It's a little more work but unless you're very careful, it's essential. Nearly all code using alloca or C99 vla's is vulnerable to stack overflow attacks, and in many implementations, they can lead to privilege elevation. There's no portable way to know how large the stack is or how much stack space is left (or how much overhead beyond the requested size might be needed for the compiler's internal use or further function calls), so the only reasonable thing you can do to make vla's/alloca safe is impose extremely small artificial limits on the size of data you support (e.g. a few kb). At this point you might as well just be using plain non-variable-length automatic objects...

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 5
    Heap is completely replacing stack. Nope. – Edgehog.net Sep 07 '16 at 03:46
  • 1
    In real-time contexts it is essential to only use the stack and avoid heap memory (malloc/free/new) since allocations could halt the thread for seconds when the system needs to swap pages to disk. – diemo Jun 03 '19 at 15:29
  • 1
    @diemo: Neither of those claims is true. Using stack *could* result in paging (if stack pointer crosses into a new page and the page has not yet been instantiated or was swapped out or discarded) and using allocated ("heap") memory need not be able to cause swapping (e.g. if there is no disk). – R.. GitHub STOP HELPING ICE Jun 03 '19 at 15:52