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

Alejandro Colomar
2025-10-29T10:58:24Z

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

On Wed, Oct 29, 2025 at 05:30:12AM -0500, G. Branden Robinson wrote:
> Hi Alex,

Hi Branden,

> At 2025-10-29T11:15:13+0100, Alejandro Colomar wrote:
> > On Wed, Oct 29, 2025 at 03:42:00AM -0500, G. Branden Robinson wrote:
> > > 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. :)
>
> I should have known I couldn't slip that example past you. ;-)

:-)

> > > 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?
>
> I don't know the Linux kernel well enough to say.

Hmmm, then I'll reuse the old wording for that, which said it was
likely.

> I don't know why we
> still name signals after hardware traps on the PDP-11 and VAX. Well, I
> do, but I'm not happy about it. It's yet another case of claiming
> portability wins by rearchitecting the world to look like old hardware.
>
> https://queue.acm.org/detail.cfm?id=3212479
>
> > Here's somethingvery similar, with s/does/fails/ in the last sentence.
>
> Yes, that's an improvement on my suggested wording. It keeps "does"
> from working as a "pro-verb" (cf. "pronoun"); the reader does not have
> to scan backward in the sentence to find out what action is referred to.

I've now also replaced 'If it fails' by 'If the allocation fails', to
avoid confusing programmers to think that 'it' may refer to the
function (that is, to think that the function can somehow return NULL).
That would conflist with the previous sentence, so it's not necessary,
but I think this is more readable by being more explicit.

Author: Alejandro Colomar <alx@kernel.org>
Date: Wed Oct 29 11:52:52 2025 +0100

man/man3/alloca.3: wfix

Reported-by: Alejandro Colomar <alx@kernel.org>
Cc: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Suggested-by: "G. Branden Robinson" <branden@debian.org>
Co-authored-by: "G. Branden Robinson" <branden@debian.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/man/man3/alloca.3 b/man/man3/alloca.3
index 52b87a8a3..367de81d0 100644
--- a/man/man3/alloca.3
+++ b/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 the allocation fails,
+the program is likely to receive a
.B SIGSEGV
-signal if it attempts to access unavailable space.)
+signal.
.P
On many systems
.BR alloca ()

Would you mind signing the patch?

Have a lovely day!
Alex

>
> Regards,
> Branden

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