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

наб
2025-10-29T15:32:53Z

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

Hi!

On Wed, Oct 29, 2025 at 03:42:00AM -0500, G. Branden Robinson wrote:
> 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.
(I think if you want to be quaint you could say that embedded
negatives are negatives for the purposes of "neither" and the like,
even after lexicalising so far you can't analyse them in modern english:
im-possible n[ot]-either n[ot]-or, as you demonstrate below.)

> Neither wolverines nor beavers have yet self-domesticated.
> Neither C nor C++ are good language choices for novice programmers.
>
> 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 don't disagree but I'd say it doesn't matter? "How the stack actually
works" for our purposes of overallocating is really neither here nor there
and changes depending on the system (grows up/down)
and hardening (guard pages y/n), but the pitfall is similar regardless.

Classical wisdom for alloca()/blowing the stack in general is you don't
know you did it until you accessed some byte of your stack that you
actually can't see, and the allocation is infallible for this reason,
and AFAIK this holds in present day.

I'll agree that the wording above is not my best work.

Given the above, I'd go for something closer to
It's impossible to know how much stack space the caller has
remaining, so alloca() can't return a failure. When stack space
has been exceeded, a SIGSEGV will be generated when writing to or
reading from an out-of-memory region.
(maybe an ", or during allocation" but idk if any alloca implementation
actually pokes the allocated area anywhere?
ISTR some discussion about large stack allocations and poking at
least once per page to grow the stack correctly with guard pages
present(?).
Conversely, "will" matches getrlimit(2), but seems very strong;
idk if it's a "may generally but will on linux" or if it's still
a "may" universally and it's still possible to crash the stack
into your normal program area on linux. or if it just depends).

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

This seems to be semantically similar to your sample,
so I'd say we're in accord.

The wording downthread seems solid.

Best,