Jay wrote:

> My explorations in Macsbug last fall led me to a slightly different 
> conclusion. It's true that local _arrays_ are put on the stack, but it 
> looks to me as if other local variables are in a handle (locked during FN 
> execution) located in the heap. 

I tried tracing a simple function through MacsBug just now, and it still
looks to me as though non-array local variables are on the stack.  My
test function has 6 short-integer variables (comprising a total of 12
bytes).  One of the first things the function does is subtract 12 from
the stack pointer (A7), essentially reserving 12 bytes on the stack.  It
then copies A7 to A6.  From then on, it refers to all the local
variables as offset from A6 (the offsets ranging from 0 bytes to 10
bytes), which means they're all within that 12-byte area of reserved
stack space.

Now the stack can _also_ be within a Heap Zone, but I don't think that's
considered part of the application's "heap."  (In my previous message I
pretended there was just one "heap" so as not to complicate the issue.) 
In fact, when I did a "WH" command to locate my 6 variables, I found
that they were in a locked relocatable block within the Process Manager
Heap (but far from the block's beginning).  Yet they were _also_ "on the
stack," because the stack pointer itself pointed to an address within
that block!

So I think the real story is that the Process Manager heap zone can
contain a relocatable block which _itself_ is a (smaller) heap zone
which contains the whole application--including the application's heap,
the application's stack, and the application's globals.  So you can have
blocks within blocks.  But this makes my head swim, so I usually just
think of one "heap" at a time. :-)

- Rick