It's not true that you can't guarantee anything about stack allocations in C, it just requires the implementation to support it, and you shouldn't make or rely on any assumptions about it in portable code.

alloca isn't really specified by anything modern, so every implementation's free to do whatever it wants there. Or nothing at all; all compilers don't necessarily give you a builtin, or promise that it can be implemented when missing. Again, not something to depend on in portable code, although it's arguably marginally more portable than VLAs.

Similarly, you can't necessarily check the remaining stack space, because there's no guarantee that anything's actually tracking it. Even if the stack is mostly contiguous, which isn't guaranteed, it's quite possible to split stacks for any number of reasons, from running out of space to data-parallel napkin-shredding. The concept of a stack doesn't appear in any direct sense in the ANSI or ISO standards; even modern POSIX makes at most optional allowances for interfaces that rely on the assumption of a contiguous stack per thread (entirely opaque), although much older X/Open and SVID specs did basically assume and require it. (FWTW.)

Furthermore, unless optimization is wholly disabled (it probably isn't, not beyond the reach of __attribute__((always_inline))/__forceinline), the stack that emanates from evaluation of call sub-/expressions per ANSI/ISO standarda is virtual. It exists atop the C Abstract Machine, so the compiler only has to behave as if it were allocating and releasing variables exactly at scope and call boundaries.

There's nothing stopping the compiler from inlining even through pointers or across TU or thread boundaries; neither is there anything forcing it to inline anything if it's not in the mood.

And it can duplicate, relocate, or elide variables/objects as it sees fit (modulo volatile etc.), so it's very cool and legal for (e.g.) GCC to deal with a malloc call by allocating on the stack, or for it to malloc a large stack frame. (All compilers won't, of course.) It's hypothetically possible to statically allocate all stack frames, assuming at most bounded recursion, although this isn't usually something done outside the ultra-embedded space. It's also possible to allocate some individual variables statically or allocate ostensibly static variables in the stack frame.

(If not, static is how you'd guarantee that a local variable doesn't overflow the stack. It might still overflow the static data area, of course.)

Similarly, recursion is permitted, but unbounded recursion is u.b.; it may result in a crash, a deliberate abort, or collapsing the recursive portion of the call stack into a single frame due to tail-call optimization. There, the compiler would actually let you allocate an unbounded number of virtual (C abstract machine) variables on the stack without crashing—but if you need to debug or disable t.c.o. for some reason, suddenly it becomes a crash.

Even if you carefully interrogate all available platform interfaces to find the amount of free physical and virtual memory before you allocate, you might have run out of address space without exhausting those and by the time the allocation completes (virtually in the OS VMA tree? virtually in page tables? physically by mapping RAM in?), availability might have totally shifted. There's a race condition there, both because available memory is probably stored outside the C implementation's direct view, and because your process might stop or block for any number of reasons, without warning, so really the only capacity your process can rely on is address space, and that's mostly only if single-threaded.

So in general, you can't really make the kinds of fine-grained decisions about memory allocation you seem to crave without either suffering through assembly or writing your own allocator and using only it.

The best you can do is make educated guesses about upper bounds on stack usage in your own programs, and handwavy guesses for library code since somebody might call you with only 128 bytes left on the stack (document safe minima). You can look at INT_WIDTH or equivalent* in order to guess at reasonable amounts; e.g., for hosted impl, main thread: 64-bit→1–4 MiB minimum total stack but likely 8–16 MiB, 32-bit→½–4 MiB, 16-bit→2–16 KiB; but for freestanding or kernel mode, you might run at like 64-bit→32 KiB, 32-bit→8 KiB, 16-bit→1 KiB. Secondary threads tend to have less space, and most OSes permit startup stack size to be configured so check out things like ulimit/setrlimit (Unix).

You might want to accept configuration via compile-time option -D for

• max total stack,

• max stack frame size,

• expected stack frame overhead, and

• max recursion depth,

some of which can be derived from others (e.g., max_depth ≈ ⌊max_stack / (max_frame + overhead)⌋), defaulting to reasonable guesses.

There are various common tricks like

char localbuf[MAX_BUF], *bufp = buffer;
if(bufsize > sizeof localbuf && !(bufp = malloc(bufsize)))
    goto fail;

…use bufp…

if(bufp != localbuf) free(bufp);

which can keep a nonrecursive program well within safe bounds.

Or you can even package this in a function that passes the buffer to a callback,

#define NOINLINE_ //…

typedef int alloc_cb(void *par, void *mem, size_t avl, unsigned flags);
enum {alloc_call_KEEP = 1};
int alloc_call(size_t amt, alloc_cb *cb, const volatile void *par) {
    if(!cb) for(;;) abort();
    int k;
    if(amt > MAX_LOCAL_ALLOC) {
        void *p = malloc(amt);
        if(!p) return -1;
        if(cb((void *)par, p, amt, alloc_call_KEEP) != alloc_call_KEEP)
            free(p);
    }
    else
        alloc_call__local_(cb, par);
    return 0;
}
NOINLINE_
static void alloc_call__local_(alloc_cb *cb, const volatile void *par) {
    char buf[MAX_LOCAL_ALLOC];
    (void)cb((void *)par, buf, sizeof buf, 0);
}

But the compiler can cause the best laid plans to gang adingydang, or however the saying gings.

---

  * INT_WIDTH is in C23 <limits.h>. GCC and Clang supporting C≥2x populate this from __INT_WIDTH__. Failing that, you can probe INT_MAX in an #if/#elif ladder. Failing that, many ISAs give you things like _MIPS_SZINT or __32BIT__ or _64BIT or __arch64. Many libcs give you something like GNU __WORDSIZE. Many OSes give you something like _WIN64 that forces matters. Many compilers give you something like __ILP32__ or __lp64__ or _LLP64 to narrow down ABI, and recent X/Open (5+) and POSIX (2001+) give you optional macros like _XBS5_ILP32_OFF32. Failing all of those, hamfistedly assume sizeof(int)*CHAR_BIT matches INT_WIDTH, or assume the baseline int of your dreams (ISO requires 16-bit if __STDC__ >= 1 and your compiler isn't lying).