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

Alejandro Colomar
2025-10-29T11:23:24Z

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

Hi Branden,

On Wed, Oct 29, 2025 at 06:12:59AM -0500, G. Branden Robinson wrote:
> 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>

I have to change the other emails now too. :)

> There ya go!

Thanks! I've pushed now.

Cheers,
Alex

P.S.: How is it going with the countof() patches in groff? :-)

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