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

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

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

Hi Alex,

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.

Neither wolverines nor beavers have yet self-domesticated.
Neither C nor C++ are good language choices for novice programmers.

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.

(I checked getrlimit(2) before composing that.)

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]