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

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).

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.

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 :-)

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.