Why should I use malloc() when "char bigchar[ 1u << 31 - 1 ];" works just fine?

Question

What's the advantage of using malloc (besides the NULL return on failure) over static arrays? The following program will eat up all my ram and start filling swap only if the loops are uncommented. It does not crash.

...

#include <stdio.h>

unsigned int bigint[ 1u << 29 - 1 ];
unsigned char bigchar[ 1u << 31 - 1 ];

int main (int argc, char **argv) {
  int i;
/*   for (i = 0; i < 1u << 29 - 1; i++) bigint[i] = i; */
/*   for (i = 0; i < 1u << 31 - 1; i++) bigchar[i] = i & 0xFF; */

  getchar();
  return 0;
}

...

After some trial and error I found the above is the largest static array allowed on my 32-bit Intel machine with GCC 4.3. Is this a standard limit, a compiler limit, or a machine limit? Apparently I can have as many of of them as I want. It will segfault, but only if I ask for (and try to use) more than malloc would give me anyway.

Is there a way to determine if a static array was actually allocated and safe to use?

EDIT: I'm interested in why malloc is used to manage the heap instead of letting the virtual memory system handle it. Apparently I can size an array to many times the size I think I'll need and the virtual memory system will only keep in ram what is needed. If I never write to e.g. the end (or beginning) of these huge arrays then the program doesn't use the physical memory. Furthermore, if I can write to every location then what does malloc do besides increment a pointer in the heap or search around previous allocations in the same process?

Editor's note: 1 << 31 causes undefined behaviour if int is 32-bit, so I have modified the question to read 1u. The intent of the question is to ask about allocating large static buffers.

Answer 1

Well, for two reasons really:

1. Because of portability, since some systems won't do the virtual memory management for you.

2. You'll inevitably need to divide this array into smaller chunks for it to be useful, then to keep track of all the chunks, then eventually as you start "freeing" some of the chunks of the array you no longer require you'll hit the problem of memory fragmentation.

All in all you'll end up implementing a lot of memory management functionality (actually pretty much reimplementing the malloc) without the benefit of portability.

Hence the reasons:

• Code portability via memory management encapsulation and standardisation.

• Personal productivity enhancement by the way of code re-use.

Answer 2

Please see:

malloc() and the C/C++ heap

Should a list of objects be stored on the heap or stack?

C++ Which is faster: Stack allocation or Heap allocation

Proper stack and heap usage in C++?

About C/C++ stack allocation

Stack,Static and Heap in C++

Of Memory Management, Heap Corruption, and C++

new on stack instead of heap (like alloca vs malloc)