Tag Klaus,

you wrote me:

 KM> But a compiler can never be sure how much stack is needed, because that
 KM> depends on runtime behaviour (a recursivly called routine will use up as
 KM> much stack space as it wants, depending on the depth of the recursion).

In my innocence i expected stack behaviour similar to: add all stack
demands of seperate functions as contained in the source file. I realize
that this behaviour, which makes sense to me, might be of no use for
another kind of application :-(

 KM> Some OS give you a huge amount of stack, that isn't really committed until
 KM> the application actually uses it.

I'll use that trick.

 KM> General rule of thumb: don't put objects larger than, say, 1k onto the
 KM> stack. Instead, get them from the heap by malloc/free.

That is easy if you start from scratch, i.e. no values are stored in the
struct: when a value is added, memory should be allocated. If a value is
altered, ultimately the memory might be reallocated if the item to be
stored is larger than the current item. Is feasible.

 KM> Especially do this in libraries which normally will use the stack of the
 KM> calling application.

It is meant to be a set of functions to be used by others. Although your
advise means a lot of work since the struct and several functions have to
be partly recoded, i will, since taking early precautions is better than
late night repairs.


73 es cuagn,
 Henk

--- GoldED 2.50+