On 6/29/2011 0:44, Lars R. wrote:
> I'd suggest something like “A recursion depth of at least 5 mus
t be
> supported by the platform. The actual limit might be higher and can be
> determined by ...”

Well, it's not even *recursion* depth, but just call stack depth.

> But such guarantee is not easily definable because the size of the
> function parameters is not limited (only their number).

Not any more. In the original version of C, you couldn't pass structs by 

value, so it would have been easier to figure out how big your arguments 
are.

> So even a recursion “depth” of 1 might fail in such pat
hetic cases.

If you don't have actual *recursive* functions, you don't need to allocat
e 
locals or arguments on the stack at all. On a machine with limited hardwa
re 
stack (like a 6502 say), you might very well generate code that will 
allocate bigger items in the heap and clean them up when you return, for 

example.

I've used Pascal compilers (on a Z-80 for example) that stored all local 

variables at fixed addresses. I don't remember how it handled recursion, 
but 
since I was writing a B-Tree library, I'm pretty sure it recursed OK.


> But statements like “Every function call might fail due to reas
ons that
> are out of scope of this standard“ are also not sensible, I thi
nk.

I think you could require a minimum amount of stack space to be available
, 
if you wanted. The standard could guarantee that the number of bytes of a
uto 
and parameter values passed not exceeding a particular value could be 
specified, if they wanted. It's not like the concept of "size of memory 
occupied" isn't common in C.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message