>>14
C1x hasn't been finalized or ratified yet. If it had been submitted for the final vote, there would have been an FDIS document, but the latest draft of the standard is just in the DIS status.
>>16
The problem with VLAs lies in the fact that VLAs created on the stack can cause stack overflows on target platforms that do not have guard pages and dynamically growable stacks. Proponents of VLAs thought there weren't really any trade offs with supporting dynamically stacks, but there are.
Additional stack probes need to be inserted during stack frame creation in every function with VLAs, leading to code bloat and performance degredation.
Additionally, relying on page faults triggered by accessing the guard page to catch the cases where needed stack size upperbound can't be determined at compile time is pretty stupid: it's slow, and on some platforms it can't be universally implemented in user-mode applications as the OS may sandbox user applications from being able to insert their own interrupt and page-fault handlers (think iOS and other locked-down embedded device OSes).
Furthermore, on 32-bit architectures, the address space is already being utilized to the max. Dynamically growable stacks work by reserving large blocks of address space, and only committing physical pages as needed. They work best where you have lots extra address space, like on 64-bit architectures. Asking everyone to give up address space in 32-bit land isn't practical.
So allowing VLAs in the absense of dynamically growable stacks can be problematic for security reasons, it has the same problem as
alloca.
>>17
It's the future.