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: 3783 bytes --]

Hi наб,

At 2025-10-29T16:22:47+0100, наб wrote:
> On Wed, Oct 29, 2025 at 03:42:00AM -0500, G. Branden Robinson wrote:
> > 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.)

As a practitioner, I don't think English grammar works that way;
sometimes whatever the semantic counterpart of a morpheme is gets bound
so tightly into a word that the word stops admitting semantic analysis
in this way.

But I'm not a trained linguist.

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

Right.  The phrasing "due to the way X works" feels like a lazy maneuver
from a technical writing perspective.  Maybe not often, but sometimes,
the programmer will want to _know_ the way stack allocations work in
Linux, because they've used alloca() and gotten themselves into trouble.
(Or maybe more likely, a colleague or former fellow employee got them
into it.)

As a rule, I think it's poor form to note the existence of an
explanation for some phenomenon without providing a citation to where
that explanation can be found.  That's what citation and footnoting
practices are _for_.  (In man pages, we can't have footnotes, but we can
have informal inline citations, and we do have the "See Also" section.)

I grant that sometimes, no explanation exists in a natural language; the
source code _is_ the documentation, and if you have enough hairs on your
chest/vested stock options/buddies who can hook you up with a new gig if
you faceplant in your current one, you go look at that source code, and
if you solve your problem, you document as little as possible and teach
no one anything.

Thus my attempt to trick some linux-mm person into wearily pointing out
the availability of ReST/Sphinx/whatever document[1] that explains
everything needs to know about the subject...which we could then cite in
the alloca(3) page.

But clever sharks are clever, and not easily fooled.

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

Agreed; I don't know of an alternative failure mode, but I've always
been pretty conservative with stack use--I grew up with irritable,
memory-starved machines--and never aggressive with alloca().

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

Given enough time, little of my own work endures the critique of my
future self.

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

I think so.

> The wording downthread seems solid.

Regards,
Branden

[1] Or, if it's really glibc that handles this in a platform-independent
    manner, then we're talking Texinfo.  Of course there are other
    libcs...

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