Is it a good idea to use C99 VLA compared to malloc/free?

Question

Is it a good idea to use C99 VLA? When is it appropriate to use VLA compared to malloc/free? (since VLA may blow up stack?)

Swimming

Avoid unexplained TLAs such as VLAs... – Ours

@Thomas: The term “VLA” has a well-established, well-known meaning in the context of C99. Someone able to answer the question will know what this means. – Melissa

Possible duplicate of: #2035212 – Rettarettig

Answer 1

Yes, except in cases where you know your stack can blow up. You can also change the size of the stack if necessary, it's different how on every OS but it's possible. The advantages of VLA are:

• Fast : adjusting the stack pointer and/or the frame pointer would have been done anyway so the cost of a VLA is nearly 0.

• Easy : a simple definition, no pointer to initialize, to check to free and no risk of memory leaks.

• It's automatically thread safe as each thread has its own stack. It has also better scaling as there's no need of locking, one problem that can arise when using malloc/free.

• Readable : it's really a simple concept, so less likely to introduce subtle bugs.

It has some drawbacks:

• Size limited : as already said, the stack can blow up.

• Buffer overflows are a bit more serious than on heap memory (one can argue that it's an advantage, as a crashing application is better than a one silently corrupting data and eventually crashing on unrelated instructions).

• Portability : not all compilers implement it, but it can often be simulated by alloca (attention the semantic is a little bit different but nothing really serious).

Magically

If you simulate using alloca()(+1) you can't use sizeof, which is often hidden inside of macros. – Cravat

Answer 2

The primary advantage with stack allocation is that you get automatic memory management of the allocated variable-length array. Since memory management is one of the core challenges for any C program, you should definitely use VLA to simplify your task, if you can.

I will then advocate that you should use VLA's consistenly when you can, and otherwise use malloc only if: You need to control the duration of the storage, and if you have very large allocations, and if you want to handle out-of-memory errors gracefully.

Saree

how large is 'very large' \o/ – Kerbing

Answer 3

Just adding another aspect (not a direct answer, as no malloc/free involved, but still related):

//
// File: someheader.h
//
// Description: Some header intended to be usable in C  a n d  C++.
//              (skipping include guards only for brevity!)
//

#ifdef __cplusplus
extern "C"
{
#endif

void f(size_t n, int(*)[n]); // OOPS: not supported by C++...

#ifdef __cplusplus
}
#endif

So it's not only because of porting, but a more general compatibility issue...

If you need such compatibility, you need to skip VLA.

Orientation

Answer 4

C++ does not support VLAs. So it will be little more effort to port the code to C++, should the need arise.

Then again, some believe this is actually a good thing and cunningly propose "class" as a wonderful name for a symbol in c :-)

Schatz

some believe this is actually a good thing and cunningly propose "class" as a wonderful name for a symbol in c :-) : Well, when one can't be better, the best way to win is to try to sabotage the competition... – Adopted

Answer 5

It is a good idea to use C99 VLAs if you have a project that you're only going to compile with a C99 compliant compiler and the alternative is to use alloca(). VLAs should not be used where you would normally use malloc() and if you don't know what alloca() does and what problems you might run into, you should not be using VLAs.

Mcbryde