The first problem is that they can be dropped from future versions of GCC. They're not part of any standard, after all.

The second problem is that there are situations in which GCC isn't the most suitable compiler. You want to minimize hacks for each different compiler supported.

Security is a big thing, too. It's hard to audit fundamentally unpredictable code.

A major step forward.

Just memory addresses. *Foo could be one or a few or many. Pointer arithmetic.

So variable arrays feels odd.

If you did not like chasing down weird memory corruption problems then you would not be using C (or C++) in the first place.

It would have been trivial to add a little bit of sanity with syntax like

void foo(char buf[blen], int blen)

so a compiler could, in debug mode, check. But no, that would not be a hero's C. nor is variable length arrays.

Incidentally, C's lack of arrays is not efficient. E.g. it

VLAs are an example of C becoming ever so slightly higher level. When the language does things under the hood without telling you it's just an invitation to bite you in the ass. Good purge.

Yes. Exactly that. It's allocating space for you. It figures out at run-time the length of your array rather than you having to do it by hand at compile-time. I didn't actually know of any security flaws this would lead to, but it stops debuggers from knowing details about calls so it obscured some information from me and pissed me off once.

This [gnu.org] is what they are referring to. Code like (from that link):

void
foo (int n)
{
  struct S { int x[n]; };
}