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

G. Branden Robinson
2025-10-29T11:13:02Z

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

Hi Alex,

At 2025-10-29T11:58:21+0100, Alejandro Colomar wrote:
> > > 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.

In principle, some linux-mm people might be lurking.

> 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.

"Clarity over all" is a basic principle of technical writing.

> 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?

Signed-off-by: "G. Branden Robinson" <g.branden.robinson@gmail.com>

There ya go!

Regards,
Branden