Thread (33 messages) 33 messages, 5 authors, 2025-10-29

Re: [PATCH 2/2] alloca.3: rewrite NOTES

From: наб <hidden>
Date: 2021-08-25 18:21:15

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,
наб

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help