Re: A stack allocation API

On Thu, Mar 12, 2026 at 2:52 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> . o O ( I originally called it stack_buffer because I started with
> "let's standardise the array trick", so it was a buffer. Perhaps a
> better name for all this stuff would be pg_stack_alloc() or such,
> since it doesn't really have a buffer anymore except in a fallback
> mode... )

* renamed like like
* hopefully improved comments and naming and structure
* replaced macros with inline functions where possible
* added many sanity and overflow checks
* added tests
* added assertions that pg_stack_free() stack pointers are known, not
double-freed
* added CLOBBER_FREED_MEMORY and ASAN use-after-
* abandoned __builtin_alloca_with_align(), it has weird scoping on GCC
* removed alloca(0)-avoidance, as zero-sized objects have normal stack pointers
* removed grows-upwards alloca support, too complicated and
practically untestable
* let's use alloca on all systems, we can just tell a CI task to test array mode
* simplified the default sizing, now it's just: 128 for arrays and
1024 for alloca()
* split main patch into a few incremental pieces that might hopefully
be more digestable

The stack is a dangerous place, so I tried hard to think of all the
ways that anything anywhere could be exploited to overflow
intermediate values etc, while also trying to prove useful things at
compile time. Ideas for other things to be paranoid about welcome.

Patches:

* 0001 + 0002 are the basic API but still using arrays
* 0003 shows the locales transformation.
* 0004..0008 add alloca()
* collection of example candidate callers, not changed much since v3,
in a tarball

One thing to highlight is how 0007 decides whether a pointer should go
to pfree() or not. I am reasonably confident that
pg_stack_upper_bound() (which is either __builtin_frame_address(0) or
stack_base_ptr) is a good authoritative bound, and I am very confident
that pg_stack_lower_bound() is reliable when it's computed as the
lowest stack address that pg_stack_alloc() has ever seen. But it
annoys me to have that book-keeping when:

pg_stack_lower_bound() can instead use __builtin_stack_address(), if
we decree that it is an authoritative lower bound, as is the case in
this patch currently. The descriptions in the Clang and GCC manuals
sound good, and the generated code is exactly what I expect: it's just
comparing with %rsp, and I haven't seen it trip my assertion that
%rsp <= every alloca(). But I wonder if some weird edge case
involving storage that is actually in a register or something like
that could allow it to not decrement %rsp, and then I wonder if that
builtin could reveal that, or something like that. I been wondering
if it might make sense to have a secondary test out-of-line that
includes a fudge factor. That sounds kinda bogus but perhaps an
argument can be constructed from guard pages: even on a system under
extreme address space pressure, palloc() pointers can only get so
close to %rsp. But that gets pretty system-specific if you want
something that holds up in court. Hnggh. Maybe I'm worrying about
nothing. Clues welcome.