[PATCH v2 5/5] alloca.3: simplfy malloc(3) suite comparison, note VLAs

наб
2021-09-14T12:41:32Z

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

alloca() is, ex definitione, always faster than any allocator that
actually, well, allocates

Like Alejandro noted, VLAs can provide a less-flexible but sometimes
better-suited solution to the same problem class

Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
---
man3/alloca.3 | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/man3/alloca.3 b/man3/alloca.3
index 936a15954..736182a7d 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -90,11 +90,8 @@ originates from PWB and 32V, and appears in all their derivatives.
The
.BR alloca ()
function is machine- and compiler-dependent.
-For certain applications,
-its use can improve efficiency compared to the use of
-.BR malloc (3)
-plus
-.BR free (3).
+Because it allocates from the stack, it's faster than
+.BR malloc (3)/ free (3).
In certain cases,
it can also simplify memory deallocation in applications that use
.BR longjmp (3)
@@ -140,6 +137,13 @@ The fact that
.BR alloca ()
is a built-in means it is impossible to take its address
or to change its behavior by linking with a different library.
+.PP
+Variable length arrays (VLAs) are part of the C99 standard,
+optional since C11, and can be used for a similar purpose.
+However, they do not port to standard C++, and, being variables,
+live in their block scope and don't have an allocator-like interface,
+making them unfit for implementing functionality like
+.BR strdupa (3).
.SH BUGS
Due to the nature of the stack, it is impossible to check if the allocation
would overflow the space available, and, hence, neither is indicating an error.
--
2.20.1