Re: [PATCH v2 3/5] alloca.3: clarify reasoning for no error return in BUGS
From: Alejandro Colomar <alx@kernel.org>
Date: 2025-10-29 10:15:16
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:quoted
On 9/14/21 2:41 PM, наб wrote:quoted
.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/>).
Attachments
- signature.asc [application/pgp-signature] 833 bytes