Am 22.06.2011 21:50, schrieb Darren New:
> Does the standard say anything about how deeply nested calls can
> recurse? I would imagine this is one of those things that's really
> difficult to standardize. Or is this one of those "implementation
> defined" things, which would also seem very difficult to control via the
> compiler on a modern OS.

Such a limit wouldn't make much sense, as the nesting of calls is 
typically limited by stack size, the use of which highly depends on the 
number of parameters and local variables in a function call. 
Consequently, according to the standard it's not even "implementation 
defined", nor is the behaviour explicitly "undefined" or "unspecified" 
if such limitations are exceeded.

In a typical software production for embedded systems, the maximum 
required stack size will be determined as part as the build process (by 
examining the call tree), and recursive function calls avoided wherever 
possible. An alternative is to run dedicated tests to determine stack 
(and heap) usage, and makes sure it does not reach the device's limits 
minus a safety margin.

In safety critical applications (e.g. car electronics), dedicated memory 
space might be set aside for a separate "high safety" task with limited 
functionality but well-analyzed requirements, which might in turn watch 
the stack usage of any "convenience" parts of the software at run-time 
(e.g. by filling some safety margin just before that software parts' 
stack limit with a predefined pattern and repeatedly checking whether 
that region remains unchanged). If the expected stack size is ever found 
to have been exceeded, the high safety task would then usually try to 
re-start the convenience tasks (to make sure they're not operating on 
corrupt data), and in case of repeated failure disable them entirely, 
possibly reducing the device's functionality to shutting down safely.

Post a reply to this message