lovecreatesbeauty said:
Richard said:
[snip]
People never declare themselves as smart ("Not Stupid") have
written Linux, GCC, etc.. I'm using both Linux and GCC, perhaps
you're using both also, or you're using the substitutes of
yourself. Can you show us some of you smart softwares? Have you got
users for them in c.l.c?
Do you think people in C standard committee all are more stupid than
you and provide you such a stupid broken feature?
(This was a response to something Richard wrote; see upthread for
context.)
I never said that anything or anyone was "stupid".
If you view VLAs as an alternative to malloc() (the only portable way
in C90 to do the equivalent kind of allocation), VLAs have the
disadvantage that there's no way to detect or handle an allocation
failure. If the system can't allocate enough memory, the behavior is
undefined. malloc() by contrast, safely returns a null pointer on
failure.
Yes, it's true that VLAs are just like ordinary objects in this sense;
there's not much difference between this:
int arr[1000000];
and this:
int len = 1000000;
int vla[len];
(apart from the latter being illegal in C90). The difference is that
a VLA can cause an allocation failure that depends on the value of a
variable at run time, perhaps on user input.
I'm not sure there's any good way to design VLAs that would eliminate
this problem. I suppose an allocation failure could cause &vla to be
NULL, but that's ugly. A generalized exception mechanism in which any
allocation failure of an automatic variable raises an exception that
can be handled by the function's caller would do the trick, but that
would be a major change to the language.
I'm not saying that VLAs shouldn't have been added to the language,
just that you have to be careful using them -- and sometimes being
careful isn't enough.