5 ms·
C99 has VLAs and there is always man 3 alloca
by rkta 3y ago
C99 has VLAs and there is always man 3 alloca
- pjmlp 3y agoDeprecated in C11 as it was acknowledged how bad idea they were in first place.
- coldtea 3y agoC99 is a much newer standard though. 1911 C was very primitive, pre-ansi C, basically an assembler for Babbage machines.
- pjmlp 3y agoLooking forward to the Analytical Engine compiler backend punch cards.
- rkta 3y agoVLAs have been deprecated, alloca was never part of a C standard AFAIK. I was not suggesting that any of both is a good idea - but they are tools 'for programs where the amount of items you must store is only known at run time.' (Assuming that not having to free is considered "automatic memory management").
- mort96 3y agoDeprecated? I thought they were only made optional?
- pjmlp 3y agoWhich allows any compiler that never implemented C99 to be certified as compliant on later standards (C11, C17, C23), thus yielding the same outcome in practice.
- mort96 3y agoThe status of VLAs is officially the exact same as the status of 'uint32_t' and the like, so I think it's fair to say there's a significant difference between something being optional (a la uint32_t) and something being deprecated (a la gets). But I agree, in practice, the change to VLAs feels more deprecation-like, because they got demoted to optional because everyone more or less recognised that they're a bad idea, I don't imagine GCC will remove it any time soon but I wouldn't be surprised if it got options to disable them and if those options eventually became enabled by default.
- rkta 3y agoCorrect, they are optional, not deprecated. That was sloppy on my side.
- coldtea 3y agoIf you use alloca that's not "automatic memory management" is it?
- rkta 3y agoInteresting. If I think 'automatic memory management' in C I think about not having to free. Of course you are right that it's not the same as using e.g. a Python List.
- mort96 3y agoWhy would alloca be more manual than allocating a sufficiently large statically sized array, or allocating variable stack memory with VLAs?
- coldtea 3y agoWell, for starters, because you expicitly call to allocate. A static array is implicitly allocated by saying you want an array. Furthermore, neither does any memory management, the memory is retained till the end of the program. "Simple memory acquisition" perhaps, "memory management" not, except if we accept it as a degenerate case, where things aren't even freed except when the program ends.
- mort96 3y agoYou may be thinking of malloc. Memory allocated by alloca is allocated on the stack, so it lives until the end of the stack frame. And the difference between 'char buf[size]' and 'char *buf = alloca(size)' isn't significant enough to put the two in separate paradigms IMO, just slightly different ways of writing the same thing.
- coldtea 3y ago>You may be thinking of malloc. Memory allocated by alloca is allocated on the stack, so it lives until the end of the stack frame. I see, but you still have to ask nicely for it explicitly.
- bruce343434 3y agoThere's still significant drawbacks, mostly that the data only lives during the lifetime of the scope.
- pkkm 3y agoThese are usually discouraged. If there's small upper bound on the size you'll need, type array[MAX_SIZE] is more efficient and harder to mess up [0]. If there isn't, you should use the heap. [0] For more details, see e.g. https://nullprogram.com/blog/2019/10/27/ https://nullprogram.com/blog/2019/10/27/
- rasz 3y agoVLAs dont seem to be all that hot. https://news.ycombinator.com/item?id=18323938 https://news.ycombinator.com/item?id=18323938 The Linux Kernel Is Now VLA (Variable-Length Array) Free (phoronix.com)