Array or Malloc?

The main difference is that VLAs (variable length arrays) provide no mechanism for detecting allocation failures.

If you declare

char result[len];

and len exceeds the amount of available stack space, your program's behavior is undefined. There is no language mechanism either for determining in advance whether the allocation will succeed, or for determining after the fact whether it succeeded.

On the other hand, if you write:

char *result = malloc(len);
if (result == NULL) {
    /* allocation failed, abort or take corrective action */
}

then you can handle failures gracefully, or at least guarantee that your program won't try to continue to execute after a failure.

(Well, mostly. On Linux systems, malloc() can allocate a chunk of address space even if there's no corresponding storage available; later attempts to use that space can invoke the OOM Killer. But checking for malloc() failure is still good practice.)

Another issue, on many systems, is that there's more space (possibly a lot more space) available for malloc() than for automatic objects like VLAs.

And as Philip's answer already mentioned, VLAs were added in C99 (Microsoft in particular doesn't support them).

Variable-length automatic arrays were introduced to C in C99.

Unless you have concerns about backwards comparability to older standards, it's fine.

In general, if it works, don't touch it. Don't optimize ahead of time. Don't worry about adding special features or clever ways of doing things, because you often aren't going to use it. Keep it simple.

If your compiler supports variable-length arrays, the only danger is overflowing the stack on some systems, when the len is ridiculously large. If you know for sure that len is not going to be larger than a certain number, and you know that your stack is not going to overflow even at the max length, leave the code as is; otherwise, rewrite it with malloc and free.

Generally speaking the stack is the easiest and best place to put your data.

I would avoid the problems of VLAs by simply allocating the largest array you expect.

There are however there are cases when the heap is best and messing around with malloc is worth the effort.

1. When its large but variable amount of data. Large depends on your environment > 1K for embedded systems, > 10MB for a Enterprise server.
2. When you want the data to persist after you exit your routine, e.g. if you return a pointer to your data. Using
3. A combination of static pointer and malloc() is usually better than defining a large static array;

I like the idea that you can have a run-time allocated array without memory fragmentation, dangling pointers, etc. However, others have pointed out that this run-time allocation can silently fail. So I tried this using gcc 4.5.3 in a Cygwin bash environment:

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

void testit (unsigned long len)
{
    char result [len*2];
    char marker[100];

    memset(marker, 0, sizeof(marker));
    printf("result's size: %lu\n", sizeof(result));
    strcpy(result, "this is a test that should overflow if no allocation");
    printf("marker's contents: '%s'\n", marker);
}

int main(int argc, char *argv[])
{
    testit(100);
    testit((unsigned long)-1);  // probably too big
}

The output was:

$ ./a.exe
result's size: 200
marker's contents: ''
result's size: 4294967294
marker's contents: 'should overflow if no allocation'

The overly large length passed in the second call clearly caused the failure (overflowing into marker[]). This doesn't mean that this kind of check is fool-proof (fools can be clever!) or that it meets the standards of C99, but it might help if you have that concern.

As usual, YMMV.

In embedded programming, we always use static array instead of malloc when the malloc and free operations are frequent. Because of the lack of memory management in embedded system, the frequent alloc and free operations will cause memory fragment. But we should utilize some tricky methods such as defining the max size of array and using static local array.

If your application is running in Linux or Windows, it is no matter using array or malloc. The key point lies in where you use your date structure and your code logic.

Something that nobody has mentioned yet is that the variable length array option is probably going to be vastly faster than malloc/free since allocating a VLA is just a case of adjusting the stack pointer (in GCC at least).

So, if this function is one that is called frequently (which you will, of course, determine by profiling), the VLA is a good optimisation option.

Another aspect to consider:

In your example, you are sending the results over the network and presumably throw away the array when you're done. This approach avoids worrying about memory management and the need to free allocated memory.

If you need to preserve the results of that array in order to pass it around to other functions, malloc may serve you better. Allocating the memory for the array will provide persistence outside the scope of that routine. Of course, you'll need to remember to free that memory as well when you're done with it.

You didn't mention the driving reason as to why you are considering changing the routine. If performance is an issue, you can consider using static members as well as allocating a block of memory elsewhere and passing it into this function for processing.