A GCC -fstack-protector vulnerability on arm64

I think the significant difference is that heap limits are system-wide, while stack limits are per-thread and much smaller. If you're developing for a multitasking environment, then overallocating heap will harm the user's ability to run other tasks, so you should try to minimise your allocations. But overallocating stack will have negligible impact on the system (unless you have thousands of threads, but you shouldn't do that anyway).

If you're developing for a single-application embedded environment, then I think it often *is* a good idea to calculate your worst-case heap usage and statically allocate that, so you can be sure the application will meet its specification and won't crash from resource exhaustion when given a valid input. Limited dynamicity can be done with statically-sized pool allocators, where higher-level code allocates a whole complex data structure and allocation failure can either be prevented (e.g. by verifying the resource requirements of a request before accepting it, or applying backpressure to a message queue before you get overloaded, etc) or handled gracefully (unwinding the operation and returning a meaningful error to the user), in contrast to a global heap which might fail in any of your many thousands of low-level std::vector/etc operations where it's practically impossible to recover except by crashing and restarting the whole application.