4 ms·
… and embedded, of course. The main problem is that there IS a limit, and you have no idea what the limit is. The only way you find out is when you crash.
by m_eiman 5y ago
… and embedded, of course. The main problem is that there IS a limit, and you have no idea what the limit is. The only way you find out is when you crash.
- trasz 5y agoThere is - in embedded (also kernel), but not in general purpose systems, like the Unix userspace. And the same piece of software very rarely runs on both. So, again, what’s the point of this exercise?
- StillBored 5y agoPeople have differing opinions of "embedded" but I would claim that most embedded uses cases the stack is actually specified by the programmer via linker scripts and/or manually setting it up during early bootstrap. Plus, its not exactly hard in most of these environments to write target and/or compiler specific macros which detects top of stack and can runtime check it via DEBUG() like macros or modifying function entry macros. None of this is of course portable, but neither is code designed to run in 1-16k of RAM and a few more K of flash. OTOH, there seem to be a lot of "we don't control anything" IoT devices which are random overly powerful processors with random uboot+linux kernels+rootfs's running my_first_c_program.c level applications. All of it tossed together with very little engineering effort, and frequently less low level knowledge, and left to rot because its basically unmaintainable, even if it happens to be the 1% of devices that can get over the air updates.
- formerly_proven 5y agogcc's -fstack-usage works well, at least for the kind of C I write on small microcontrollers. You still have to add it up manually across the callgraph and of course take ISRs into account.
- kevin_thibedeau 5y ago> The only way you find out is when you crash. You can fill the stack region with sentinel data and periodically scan it to warn of impending doom.