Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: stack overflow error
Message-ID: <17241@dartvax.Dartmouth.EDU>
Date: 24 Nov 89 00:58:44 GMT
References: <802@lclark.UUCP>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 39

In article <802@lclark.UUCP> dan@lclark.UUCP (Dan Revel) writes:
...
>I tried using GetApplLimit and SetApplLimit just after calling MaxApplZone
>at the beginning of my program, I adjusted the limit downwards thinking
>that that would shrink the heap size and thereby allow a bigger stack.
>all I got for my efforts was a bomb!

You have to call SetApplLimit first, then MaxApplZone.  SetApplLimit
sets the application heap limit, while MaxApplZone expands the heap to
this limit.  It is not logical to call them in the other order.

Instead of using GetApplLimit, you can calculate the desired heap end
address by subtracting the desired stack size from the current stack
pointer while in the top level of your program.  This easy in
assembler.  In a high level language, the same effect may be obtained
by taking the address of a local variable, thusly:

main()
{
	/* some vars */

	long stackframeend;			/* Last auto var in main. */

	SetApplLimit( (char *)(& stackframeend) - DESIRED_STACK_SIZE );
	MaxApplZone();

This is what I always do.  Note that GetApplLimit is not a real trap
call, but is either glue or inline code to dump a low memory location.
If low memory globals go away, GetApplLimit dies until you get new
interface files, and you will have to recompile and reship your
application.  My method will always work, and is more direct.
Even more direct is the following, if you can assemble code:

	movea.l	a7,a0
	suba.l	#DESIRED_STACK_SIZE,a0
	_SetApplLimit
	_MaxApplZone

Earle R. Horton