4 ms·

VLAs provide a very useful way to avoid making temporary allocations using malloc()/free(), allowing (generally) better speed & avoiding leaks. Why do you beli

• pascal_cuoq 11y ago
  Because malloc() can signal failure to allocate by returning a null pointer. VLAs make it impossible to handle a failure to allocate: there is no interface to indicate what the program should do when it happens. You can only follow the declaration of a VLA with code that assumes that the allocation succeeded.
  • yongjik 11y ago
    But you can say the same about function calls: it may trigger stack overflow, but there's no interface to tell what to do in that case.
  • uxcn 11y ago
    This is why I avoid allocating large VLAs, and using them in deep call stacks in general. There's a diminishing return for allocating on the stack beyond a certain point anyway (roughly around a page). Having a mechanism to abstract this might be nice, but these are things people should hopefully be aware of before using VLAs. std::dynarray has been a bit polarizing though.
  • _kst_ 11y ago
    Exactly the same thing applies to fixed-size arrays. If you define a local array of N elements, there's no defined way to signal an allocation failure whether N is a compile-time constant or not.
    • _kst_ 11y ago
      Expanding on the above, if you create a VLA with an unchecked size derived from user input, you've got problems. If the user provides a size bigger than you can allocate, your program could crash if you're lucky. (If you're not lucky, it might appear to work but behave unpredictably.) On the other hand, if you're currently allocating a fixed-size array that's big enough to hold, say, 1024 elements (of which you're only going to use some initial subset), then replacing it with a VLA that's the exact size you need (<= 1024) will be an improvement. malloc() is supposed to safely tell you whether an allocation succeeded or failed, but in practice it doesn't do so reliably. On Linux, by default, it can allocate a huge chunk of address space, and then fail (with no way to handle the failure) when you try to access it. When that happens, it can invoke the "OOM killer", which can kill other processes.
  • jws 11y ago
    But malloc() doesn't always signal failure with a null in many modern systems. It will happily return you a region of unpopulated virtual address and then SIGSEGV you when you try to use it. (With overcommit). I think we can leave VLAs in the "trust the programmer" category. Very handy with bounded sizes; it keeps you from wasting all those warm cache lines.
    • nwmcsween 11y ago
      The OS is working around sloppy programs by allowing overcommit which is in itself sloppy (imo), if you can't trust the kernel itself the language can't really save you.
• rkangel 11y ago
  It turns out that ARMCC generates a call to malloc when you use a VLA. Was a bit of a suprrise when I used one in an ISR explicitly to AVOID malloc. Apparently the lack of a frame pointer on ARM means that tracking dynamically sized stack frames is a problem.