On Tue, Aug 24, 2021 at 12:33:56PM +0200, Alejandro Colomar (man-pages) wrote: > Hello Ahelenia, (do you prefer наб or Ahelenia? What does наб mean, if I > may ask? :) Either works, prefer former, but this is neither the time nor the place for nomenclatural epistemology. > AFAIK, VLAs are 100% equivalent to alloca() (except for the obvious syntax > differences). And considering the VLA syntax is much nicer than alloca(), > and is in the standard (IIRC, C99 added VLAs, and C11 declared them > optional), what about adding a NOTES subsection that recommends (or at least > mentions) VLAs? > > And they both share the problem of smashing the stack if you try to allocate > an array to big (and none of them has a way to check if it will happen, > AFAIK). Well, the fundamental difference is that VLAs are arrays of objects with odd semantics and alloca() (a) has an allocator-like interface and (b) returns uninitialised memory, that, as you note in your second mail, (c) escapes into a larger (function) scope. Plus, I've usually found VLAs to be used by accident because something in the array dimension wasn't as constexpr as expected (the macros surrounding unix(7) SCM_RIGHTS on Darwin come to mind, try explaining that to a conformant C++ compiler), while alloca() makes the potentially-unbounded allocation obvious (and portable). That being said, you do have a point, I'll mention VLAs in v2. Best, наб
Attachment:
signature.asc
Description: PGP signature
