unreliable variable length array allocation about cfiles HOT 6 CLOSED

    // Stores number of files in the child directory
    len_preview = getNumberofFiles(next_dir);
    // Stores files in the child directory
    char* next_directories[len_preview];
    status = getFiles(next_dir, next_directories);
    if status == -1:
        continue;

Will the status check solve this problem?

from cfiles.

No, it will blow out your call stack. Call stack is meant for small and relatively fixed-sized arrays.
For your cases, I think the best approach is to allocate it on heap.

FYI, I use my Stensal SDK (https://stensal.com) to build and test your code, and found this problem.

from cfiles.

If I use malloc, the code will look like this:

        // Stores number of files in the child directory
        len_preview = getNumberofFiles(next_dir);
        // Stores files in the child directory
        char** next_directories;
        next_directories = (char **)malloc(len_preview * sizeof(char *));
        /*
            Rest of the code goes here
        */ 
        // Free Memory
        for( i=0; i<len_preview; i++ )
        {
            free(next_directories[i]);
        }
        free(next_directories);

So will this be enough?
Also I have used a similar declaration for char *directories[len];. So why is it the case that it is not wrong? Should I use malloc in that case too?

from cfiles.

I only see the allocation for next_directories. Presumabily you also allocate for each of next_directories[i]. If it is the case, yes, it's more reliable than allocating on call stacks.

It's not about right or wrong. It's less reliable and you can exhaust call stack quickly. The limit of call stack is much smaller than the limit of heap.

from cfiles.

I made the relevant changes in the latest commit 9be9889.
Let me know if this is good enough for closing this issue. Thanks!

from cfiles.

See #11

from cfiles.