> Personally I'd rather see real-world extensions from gcc and clang moved into the standard which are already battle proven instead of wasting time fixing 30 year old problems.
there's nothing that prevents you from using clang on all platforms, which will be exactly the same experience that if you used $LANG_WITHOUT_AN_ISO_STANDARD
Oh but there is :) As a library author I really don't want to dictate users what compiler to use, they should at least be free to choose between the "big 3": gcc, clang and MSVC. Having those 3 compilers agree on more language features would be very helpful (this doesn't even need to happen through the standard, it would be enough if gcc, clang and MSVC would agree on a handful of important non-standard extensions).
I use a clang/libc++ toolchain to target Linux, macOS and Windows - works like a charm. It's also the toolchain used by Android and iOS, and I could also do some WASM with it. So portability here is definitely not an issue to me
c'mon, clang is able to target x86&64, ARM, AArch64, MIPS, AVR, RISC-V, WASM among others - those combined are 99.9% of the market (and 100% of the market for desktop apps).
Putting VLA in the stack is just an implementation choice. A conforming implementation could allocate all VLA in the heap (and freeing the memory upon scope loss), or do not even use a stack/heap system at all. In that sense, VLA are a crucial language feature to allow a RAII-style for C code. Essentially, you could replace this
void f(int n, ...)
{
float *t = malloc(n * sizeof*t);
// do stuff with t[i]
free (t);
}
with the following semantically equivalent code
void f(int n, ...)
{
float t[n];
// do stuff with t[i]
}
Today, this is not a good idea for large arrays because, unfortunately, many C implementations put VLA in the stack. I hope that by keeping VLA in the standard language, future C implementations will get to favor this usage.
Notice that VLA are not more dangerous or risky than recursion. The exact same argument that you use against VLA can be used against recursion. Are you against recursive functions in C? Of course, you wouldn't traverse a long array using recursion, but if you are careful that the depth of recursion is logarithmic with the array size (e.g. as in binary search), then it is perfectly safe and reasonable to use recursion. The same thing with VLA. If you are sure that n is 2,3 or at most 4 there's no reason to avoid VLA due to stack scare, and they may make your code much simpler, clearer and better.
On the other hand, VLA are useful even if you do not use them to allocate memory. Pointers to vla can be used for many things, for example accessing a one-dimensional array (allocated by a single call to malloc) using two indices as if it was a 2d array.
Yes they are still there are optional, which basically means that other than clang and gcc, no other C compiler is going to bother supporting them anyway.
Google has sponsored a 2 year effort to remove all VLAs from Linux kernel, that is how much love they get from the security industry.
> other than clang and gcc, no other C compiler is going to bother supporting them anyway.
I understand that you have some sort of personal grudge against VLA, but there's no need to use misinformation to further your agenda. VLA are supported by all C compilers except Microsoft's. More precisely, they are supported by gcc, clang, icc, tcc and oracle developer studio (suncc), as well as several other experimental C compilers that seem to be written for fun as a learning experience.
I understand that it makes sense to avoid some language features on an OS kernel, like VLA or recursion. For example, it would make sense to avoid types of ambiguous size such as "int". This does not mean in any way that using "int" is wrong in all cases. Many algorithms (I think about mathematical and numerical codes) are very naturally expressed using these fancier language features.
You can make a very valid case for language simplification and against VLA and other "modern" features. But your argument is less powerful if you sound ignorant of the widespread support and uses of these features.
Everyone that cares about security hates VLAs, that is why ISO acknowledged the mistake of placing them into C99 and removed them from the standard in C11.
Also why Google's Kernel Self Preservation project for Linux has sponsored the 2 year effort that it took to clean up Linux from VLA usage.
You arguments for VLA adoption are meaningless when companies like Google and Microsoft are voting with their wallets against them, and WG14 has acknowledged their mistake.
Love and hate are emotional considerations not really worthy in this context. I would say that everybody that sees C as a valid replacement of Fortran loves and relies on VLAs and complex types. And there's probably much more people in the world interested in numeric codes than in "security" codes.
> that is why ISO acknowledged the mistake of placing them into C99 and removed them from the standard in C11.
This is most certainly not true. First, I'm almost sure that ISO never acknowledged any mistake with VLAs. Can you point me to where ISO acknowledged that purported mistake?
More importantly, your statement is false because ISO never removed VLA from the standard. That would be untoward and very contrary to their traditions. If they really wanted to remove them they would start by first deprecating them, and they are not deprecated. They are merely an optional feature of the language, just like the "main()" function is. The standard defines different kinds of conforming implementations, and some of them include VLA. Thus it is an official part of the language.
Anyone that knows ISO standardese knows that when a feature moves from compulsory into optional, it is a synonum for deprecated, as compilers that haven't yet adopted the specific feature never bother to spend resources implementing it.
You should read the link contents before posting them here.
"In particular, the order of parameters in function declarations should be arranged such that the size of an array appears before the array. The purpose is to allow Variable-Length Array (VLA) notation to be used."
Notation for what?
"Application Programming Interfaces (APIs) should be self-documenting when possible."
And why is that?
"This not only makes the code's purpose clearer to human readers, but also makes static analysis easier. Any new APIs added to the Standard should take this into consideration. "
On top of that, if you bother to actually read the ongoing C2X mailings, there are no plans to bring VLAs back to life, besides adopting the syntax to describe function parameters.
Most devs that take security seriously actually take the effort to know the details of the devil that we have to deal with.
You didn’t address any of his points and your rebuttals come across as little more than frantic handwaving. Moreover, as has been pointed in this post, VLAs don’t necessarily need to have security implications since they can be implemented outside the stack. Yet you keep bringing up Google and KSPP as if they are arbiters of truth instead of corporate entities with their own agendas.
You are also spreading misinformation. VLAs being optional does not mean they have been removed from the standard as you keep claiming.
Already done in C11, they were marked optional, so any compiler that jumped from C89 to C11 (we are on the edge of C2x now), isn't required to even bother themselves with VLAs and will still achieve C11 certification (C17, C2X,...)
it's an answer to the parent's claim that the "big" three compilers are gcc, clang and msvc. I guess they meant that in the sense of "the most relevant", or "the most used". While microsoft's is unarguably an important C++ compiler, it's rarely used for non-legacy C code.
there's nothing that prevents you from using clang on all platforms, which will be exactly the same experience that if you used $LANG_WITHOUT_AN_ISO_STANDARD