[PATCH v2 0/5] alloca(3) commentary re-write

наб
2021-09-14T12:40:55Z

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

Hi!

This again, I think I cracked it into sensible chunks (see below)
and addressed most-all reviews (reviewers CC:d).

I also reduced the overly-verbose flag list (which was already missing
-std=c18) to "standards conformance (-ansi, -std=c*)", added a VLA
paragraph, and elucidated on the commit messages (#1 even has references
and everything).

наб (5):
strdup.3: drop mention of "the GNU GCC suite"
alloca.3: clarify origins in CONFORMING TO
alloca.3: clarify reasoning for no error return in BUGS
alloca.3: remove GCC faffling from NOTES
alloca.3: simplfy malloc(3) suite comparison, note VLAs

man3/alloca.3 | 76 +++++++++++++++++++--------------------------------
man3/strdup.3 | 3 --
2 files changed, 28 insertions(+), 51 deletions(-)

Interdiff against v1:
diff --git a/man3/alloca.3 b/man3/alloca.3
index 133ca6ab3..736182a7d 100644
--- a/man3/alloca.3
+++ b/man3/alloca.3
@@ -90,7 +90,7 @@ originates from PWB and 32V, and appears in all their derivatives.
The
.BR alloca ()
function is machine- and compiler-dependent.
-Because it allocates from the stack, it's always faster than
+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
@@ -124,28 +124,32 @@ By necessity,
.BR alloca ()
is a compiler built-in, also known as
.BR __builtin_alloca ().
-By default, modern compilers automatically translate plain
+By default, modern compilers automatically translate all uses of
.BR alloca ()
-calls, but this is forbidden if
-.IR "\-ansi" ,
-.IR "\-std=c89" ,
-.IR "\-std=c99" ,
-or
-.IR "\-std=c11"
-are specified, in which case
+into the built-in, but this is forbidden if standards conformance is requested
+.RI ( "\-ansi" ,
+.IR "\-std=c*" ),
+in which case
.I <alloca.h>
-is required, lest an actual symbol dependency is emitted.
+is required, lest a symbol dependency be emitted.
.PP
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
-As it's untestable, there is no error indication if the allocation
-would overflow the space available for the stack.
+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.
(However, the program is likely to receive a
.B SIGSEGV
-signal if it attempts to access that space.)
+signal if it attempts to access unavailable space.)
.PP
On many systems
.BR alloca ()
--
2.20.1