Hallo Henk!

Am 16.03.97 schrieb Henk den Adel folgendes zum Thema "trap 0005" an All:

/snip/
 HdA> The reason for this message is a struct, which is 40 kB in size.

This tends to be dangerous... as you found out.

 HdA> When i changed:
 HdA>    struct desc heads;
 HdA> into:
 HdA>    static struct desc heads;
 HdA> problems are solved under OS/2 and DOS; the reason probably is that
 HdA> the struct is placed in the data segment.

Yes.

 HdA> The same result (under OS/2 and DOS) could be achieved when static is
 HdA> omitted when simultaneously the stack size was enlarged to
 HdA> STACK:50000.

Right.

 HdA> I would appreciate if anyone could explain me why the stack is not
 HdA> automatically chosen to be sufficiently large, or better how to
 HdA> order the compiler to choose the right stack size. I'm using ibm's C
 HdA> compiler, version 2.01.

With that one, default stack size is 8k, if I remember correctly. As your
struct is larger, there is obviously a problem. But a compiler can never be
sure how much stack is needed, because that depends on runtime behaviour (a
recursivly called routine will use up as much stack space as it wants,
depending on the depth of the recursion). So there is _no_ way a compiler
can choose the "right" stack size.

Some OS give you a huge amount of stack, that isn't really committed until
the application actually uses it. Although it _is_ possible to use such a
mechanism under OS/2 (look into your compiler doc under the key word
"stack probes"), this will not help you under DOS and similar
environments without decent memory management.

General rule of thumb: don't put objects larger than, say, 1k onto the
stack. Instead, get them from the heap by malloc/free. Especially do this
in libraries which normally will use the stack of the calling application.
As the user of the library will not normally suspect huge stack demands,
your library will be made responsible for the problems that arise.

Hope this helps,

Klaus

Disclaimer: The opinions expressed are solely those of the author.
            And are most probably wrong anyway.

--- FleetStreet 1.18+