Re: [PATCH v2 3/5] alloca.3: clarify reasoning for no error return in BUGS

Alejandro Colomar
2025-10-29T10:15:16Z

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

Hi Branden,

On Wed, Oct 29, 2025 at 03:42:00AM -0500, G. Branden Robinson wrote:
> Hi Alex,
>
> At 2021-09-15T21:42:26+0200, Alejandro Colomar (man-pages) wrote:
> > On 9/14/21 2:41 PM, наб wrote:
> > > .SH BUGS
> > > -There is no error indication if the stack frame cannot be extended.
> > > -(However, after a failed allocation, the program is likely to receive a
> > > +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.
> >
> > I'm not sure this use of neither (without a preceding "not") is valid
> > English. Is it?
>
> The sentence is confusingly cast, but the problem is not as simple as
> you describe. It is common in English to use "neither" without "not"
> preceding or following.
>
> Neither wolverines nor beavers have yet self-domesticated.
> Neither C nor C++ are good language choices for novice programmers.

C is quite simple, and as a consequence, a great choice for a novice
programmer, IMO. :)

> Maybe you were expecting something like this wording:
>
> Due to the nature of the stack, checking if the allocation would
> overflow the space available is not possible, and, hence, neither is
> indicating an error.
>
> That's more grammatically conventional. However, I would recast even
> more aggressively, as I find "due to the nature of the stack" hand-wavy.
>
> I suggest something like:
>
> alloca() does not query the system for available stack memory, and does
> not fall back to using the heap if stack storage is unavailable. It
> therefore cannot indicate an error if the allocation fails. If it does,
> the system generates a SIGSEGV signal.

Is this last sentence a guarantee? Can something different ever occur?

Here's somethingvery similar, with s/does/fails/ in the last sentence.

diff --git i/man/man3/alloca.3 w/man/man3/alloca.3
index 52b87a8a3..4f4a87201 100644
--- i/man/man3/alloca.3
+++ w/man/man3/alloca.3
@@ -111,11 +111,14 @@ .SH NOTES
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.
-(However, the program is likely to receive a
+.BR alloca ()
+does not query the system for available stack memory,
+and does not fall back to using heap if stack storage is unavailable.
+It therefore cannot indicate an error if the allocation fails.
+If it fails,
+the system generates a
.B SIGSEGV
-signal if it attempts to access unavailable space.)
+signal.
.P
On many systems
.BR alloca ()

Have a lovely day!
Alex

> (I checked getrlimit(2) before composing that.)
>
> Regards,
> Branden

--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).