Hi Mike and Jeffrey,

you wrote me:

[What is missing?]

 MP> I don't see where your reasoning leads to the conclusion that the
 MP> optimum size of the *entire* stack and heap are known to the compiler.

The optimum size of the stack, that is a valid argument. Just adding
stacksizes of separate functions will not produce the optimum stacksize,
just a size which will be sufficiently large. I _do_ see that recursion is
a completely different game, as a concept it is nice, but imho it is the
text book example of shooting oneself in the foot.

 MP> What if the other function needs 45k?

Allocate 40+45 kB of stacksize.

 MP> What if the other function calls yet another function?
 JH> What if your function calls another-one and that one again calls another
 JH> one..?

add another X kB.

 MP> What if those functions engage in mutual recursion?
 JH> And what about recursion.

End Of My Solutions.

 JH> So the maximum needed size for the stack strongly depends on program-flow
 JH> and can only be determined at runtime.

What you means to say is: there is no general solution of the sufficiently
large dimensioned stack size, no solution will be provided, even non for
the most simple cases.

 MP> Since the compiler does not follow the logic of your code, it cannot know
 MP> how large to make the total stack segment.

Do you mean: due to possible recursion?

 MP> It only knows about the local stack frames, which are of a constant
 MP> size determined by your parameter and local variable declarations, not
 MP> the logic of your code.

Agree.

[Just make your stack large enough]

 MP> Under OS/2 and UNIX.  Don't try that in DOS or Win16 :)

I will not.

 MP> If you're not dealing with a braindead OS, allocate more than you will
 MP> need and let the OS deal with it.

I'll take your advise.


73 es cuagn,
 Henk

--- GoldED 2.50+