Is malloc needed for dynamic array declaration using GCC?

[Matuku]

I'm reading up on and learning about pointers in C and have read that, if you want to create an array that you'll only know the length of at runtime, the correct way to do this is using malloc:

int *iptr;
iptr = malloc(i * sizeof(int)); // i to be read in at runtime

so that you end up with a pointer to the start of the array of length i.



However, when mucking about and testing this out I found that the compiler (GCC) doesn't throw up any complaints when you use:

int i;

scanf("%d", &i);

int test[i];

Is this just a fluke of how GCC compiles it that it takes into account the dynamic memory allocation for you? Would other compilers throw up an error? Or is the second method actually allowed?

[celegorm]

Needed, no. Preferred? Yes. By using malloc you can then later call "free" to clear the memory and open it for other uses making the system leaner overall.

The real difference here is what is returned by the system. By doing things like int test[i] you're just saying we have a bunch of items to put in a list and is not a true pointer to anything, just strait values. The malloc function returns the memory address of the location that will store element 0 (the first data point) of an array, string or whatever else it might be. By setting a pointer equal to the results of malloc, you're telling the system "Hey, start here when looking for data from this pointer".

[berry120]

This is one of the very reasons why I don't recommend starting with languages such as C - the manual memory management can get confusing rather quickly!

Needed, no. Preferred? Yes. By using malloc you can then later call "free" to clear the memory and open it for other uses making the system leaner overall.

Actually, to guarantee the code works you do need malloc. Malloc allocates a chunk of memory and gives it to (in this case) the array, marking that memory as in use by the program. If you don't use malloc, you're using unallocated memory, which could potentially change, be yanked away or cause a segmentation fault at any point in the code without you doing a thing. In simple programs this is relatively easy to spot and fix, in larger ones it's hideously complicated and is the source of lots of hard to track down bugs in many programs.

As an aside, I'm sure a few years ago when a power line was pulled down by a storm, sparked and caught fire, the key to the safety system not cutting in was a misplaced malloc / free that fell foul to this very bug.

You can (and should) later call free to release the memory aquired by malloc, and this will prevent memory leaks. Calling malloc however is an absolute must - GCC won't throw up any warnings because in C reading and writing to random chunks of memory is a perfectly legal operation, just one that can cause a lot of bugs, pains and headaches later on if you don't know exactly what you're doing!

This is why generally speaking, people don't use C anymore unless there's a damn good reason